September 21, 2011, Woods Hole, MA

1. The RPI semantic development methodology: Use cases as starting points for assessing semantic web technologies that achieve project goals (aka ‘sheesh’) September 21, 2011, Woods Hole, MA Peter Fox (RPI* and WHOI**) pfox@cs.rpi.edu and OTHERS!! *Tetherless World Constellation, ** AOP&E

2. What’s ahead • Start with a vision • What’s the goal? • Attributes in collaboratories/ networks • Matching with a development methodology • Use cases, and more… • Scale • Jumping off point … to … Tetherless World Constellation

3. Vision? • “Our vision is to develop, facilitate, and maintain sustained multi-way engagement of natural and social (?) scientists and practitioners in multi-scale local to global networks” [for X]. • Organization is required so participants (3) can carry out mission(s) • Those participants (by defn.) may never be in a single organization -> virtual organization (1)

4. Goal (2) • We want to perform X involving all (or as many) stakeholders and we want robust science data presented in forms that various end-users can consume… • Or similar – a point of discussion – now or later (13)

5. (1) Virtual Organization • Outcomes/ values (4) • Dynamic versus static (5) • Evolvable/ ecosystem-like (6) • Heterogenetic tolerance (7) • Attributes of the organization (8) • Roles/ responsibilities (9) • Scale (10) or scalability

6. Virtual organizations – many defn. • ‘ …a geographically distributed organization whose members are bound by a long-term common interest or goal, and who communicate and coordinate their work through information technology’ (Ahuja)

7. Roles and relationships • ‘These members assume well defined roles and status relationships within the context of the virtual group that may be independent of their role and status in the organization employing them’ (Ahuja et al., 1998).

8. Virtual organizations as Socio-Technical Systems Technology Organizational Structure Communication Patterns

9. Communication patterns • A key feature of virtual organizations is a high degree of informal communication • Because of a lack of formal rules, procedures, clear reporting relationships, and norms, more extensive informal communication is required

10. Credit: B. Rouse (BEVO) 2008

11. Credit: B. Rouse (BEVO) 2008

12. Credit: B. Rouse (BEVO) 2008

13. Mapping • (2) goal -> use case • (3) participation -> team(s), vetting, acceptance • (4) outcomes/ vaue -> goals, metrics, evaluation, incentives, data/information/ knowledge projects, responses, decisions • (5) dynamic -> agile working format, small iterations • (6) evolution -> rapid development, evaluation and iteration (open)

14. Mapping (ctd.) • (7) heterogeneity -> information modeling approach • (8) organizational attributes -> networks (10) • (9) roles/ responsibilities -> actors in the use case • Application of social-technical (and socio-ecological) understandings leads to an informatics methodology … but 1st….

15. (10) Scale(s) • Multiple modes – spatial, temporal, discipline, etc. • Scale-free networks • Citation networks • The Web • Semantic networks • Depend on super nodes (11) • Semantic networks are ones where the nodes and relations are ‘named and typed’

16. Scale free?

17. (11) Super nodes • People (you!) • Organizations • Computational infrastructure • Data and information services • Roles/ responsibilites and resulting delegation to the smaller nodes around the super nodes

18. (12) Stimulating the network • Ecosystems need diversity, many types • SO … partnerships, coordination, networks, work, ongoing, etc.

19. What about meaning? Named and typed relationships • Sustained? • Evolved?

20. And more…

21. (13) Method • We also get a lot of other stuff for ‘free’ • Provenance (explanation…) • Extensibility • Application integration • Terminology mediation • Usually at this stage, we start on … • Use case(s), including activity diagram • Information modeling • Evaluation and iteration

22. Modern informatics enables a new scale-free** framework approach • Use cases • Stakeholders • Distributed authority • Access control • Ontologies • Maintaining Identity

23. NEFSC ESR • Goal: Efficient generation of figures and tables representing ecosystem data and information products for the bi-annual (or annual) North-east Fisheries Science Center = NEFSC Ecosystem Status Report (ESR). • Let’s look at that use case

24. NEFSC ESR

25. Systems v. Frameworks • Rough definitions • Systems have very well-define entry and exit points. A user tends to know when they are using one. Options for extensions are limited and usually require engineering • Frameworks have many entry and use points. A user often does not know when they are using one. Extension points are part of the design Tetherless World Constellation

26. Questions so far?

27. Team

28. Team: Roles and skill-sets needed • Facilitator *** (usual key skills, knows method) • Domain experts (literate, knows resources; data, applications, tools, etc.) • Modelers (to extract concepts, etc.) • Software engineers (architecture, technology) • Scribe (to write everything down) • The social aspect is key - it is a team effort Developed for NASA TIWG

29. Analysis

30. Model

31. Information Modeling • Conceptual • Logical • Physical

32. Information Models • Conceptual models, sometimes called domain models, are typically used to explore domain concepts and often created • as part of initial requirements envisioning efforts as they are used to explore the high-level static business or science or medicine structures and concepts • as the precursor to logical models or as alternatives to them • Followed by logical and physical models

33. Object oriented design • Object-oriented modeling is a formal way of representing something in the real world (draws from traditional set theory and classification theory). Some basics to keep in mind in object-oriented modeling are that: • Instances are things. • Properties are attributes. • Relationships are pairs of attributes. • Classes are types of things. • Subclasses are subtypes of things.

34. Logical models • A logical entity-relationship model is provable in the mathematics of data science. Given the current predominance of relational databases, logical models generally conform to relational theory. • Thus a logical model contains only fully normalized entities. Some of these may represent logical domains rather than potential physical tables.

35. Logical models • For a logical data model to be normalized, it must include the full population of attributes to be implemented and those attributes must be defined in terms of their domains or logical data types (e.g., character, number, date, picture, etc.). • A logical data model requires a complete scheme of identifiers or candidate keys for unique identification of each occurrence in every entity

36. Physical models • A physical model is a single logical model instantiated in a specific information system (e.g., relational database, RDF/XML document, etc.) in a specific installation. • The physical model specifies implementation details which may be features of a particular product or version, as well as configuration choices for that instance.

37. Tools

38. Tools • CMAP Ontology Editor (concept mapping tool from IHMC - http://cmap.ihmc.us/coe ) • Drag/drop visual development of classes, subclass and property relationship • Read and writes OWL • Formal convention (OWL/RDF tags, etc.) • Mindmapping • http://en.wikipedia.org/wiki/List_of_mind_mapping_software • White board • Piece of paper … you get the idea…

39. Review

40. These come later • Technology assessment • Leverage infrastructure • Rapid prototyping • Evaluation • Open world, iteration

41. Use case!

42. Use Case • … is a collection of possible sequences of interactions between the system under discussion and its actors, relating to a particular goal. • The collection of Use Cases should define all system behavior relevant to the actors to assure them that their goals will be carried out properly. • Any system behavior that is irrelevant to the actors should not be included in the use cases. • is a prose description of a system's behavior when interacting with the outside world. • is a technique for capturing functional requirements of business systems and, potentially, of an ICT system to support the business system. • can also capture non-functional requirements

43. Use Case • Must be documented (or it is useless) • Should be implemented (or it is not well scoped) • Is used to identify: concepts ~ resources, processes, roles (aka actors), relations, requirements, etc. • Should iterate with your end-user on wording and details at least once

44. Use case myths • Need lots (10s - 100s) of use cases to build what is needed • Need to be very general to get general functionality • Need to know ‘computer science’ to create them, or the diagrams • Have to get them perfect the first time • Are only used for software development • Many more …

45. Use Cases Expose System Requirements • Exposes goals, outcomes, actors/ roles, resources, preconditions, process flow, artifacts • And … semantics, terms, concepts and their relations

46. Real use cases:Marine habitat - change Rock Several disciplines; biology, geology, chemistry, oceanography Several applications; science, fishing, habitat change, climate and environmental change, data integration Complex inter-relations, questions Use case: What is the temperature and salinity of the water and are these marine specimens usual or part of an ecosystem change? Scallop, shell fragment Scallop, number, density Flora or fauna? What is this? Scallop, size, shape, color, place Dirt/ mud; one person’s noise is another person’s signal Src: WHOI and the HabCam group

47. NEFSC ESR • Goal: Efficient generation of figures and tables representing ecosystem data and information products for the bi-annual (or annual) NEFSC Ecosystem Status Report (ESR). • Let’s look at that use case

48. Use case format • Use case name • Goal • Summary • Triggers • Basic flow • Alternate flow • Post conditions • Activity diagram • Preconditions in tabular form • Notes Developed for NASA TIWG

49. Use case format? • Short (in document) format for: • Exploratory phase of a project where you want to collect a lot of use cases • An example for others to use • Including in a proposal • For activities like this! Developed for NASA TIWG

50. Scoping Focus initially on: Core functionality What it takes to implement the use case, resist early generalizations May (will) have to iterate on use case and requirements Acknowledge other important issues such as: Required vs. optional Non-functional requirements Available personnel (skills) and resources