1. The RPI/TWC semantic development methodology re-dux: Use cases, and beyond January 18, 2012 USGS, St. Petersburg, FL Peter Fox (RPI* and WHOI**) pfox@cs.rpi.edu and OTHERS!!pfox@cs.rpi.edu *Tetherless World Constellation, ** AOP&E

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

3. 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 –Platforms are built on frameworks Tetherless World Constellation 3

4. Team

5. Developed for NASA TIWG 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 So, how did it go?

6. Analysis

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

8. Goal of Analysis Get the team a shared understanding of who is in the use case, what they do and interact with, and what the stages of the use case, and relations are To get an informal visual representation of the use case that begins to sync up with the written material The order in which to do this is dependent on the team

9. Model

10. Data-Information-Knowledge Ecosystem 10 DataInformationKnowledge ProducersConsumers Context Presentation Organization Integration Conversation Creation Gathering Experience Curators

11. Information Modeling Conceptual Logical Physical 11

12. 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 12

13. 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. 13

14. 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. 14

15. 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 15

16. 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. 16

17. Conceptual model example Radiative process model after a volcanic eruption 17

18. Logical model example 18

19. Physical model example NB – does not correspond to two previous models! 19

20. For example for relational DBs 20 FeatureConceptual Logical Physical Entity Names ✓✓ Entity Relationships ✓✓ Attributes ✓ Primary Keys ✓✓ Foreign Keys ✓✓ Table Names ✓ Column Names ✓ Column Data Types ✓

21. One more example 21

22. 22

23. Physical Information Models PIMs are used to –design the internal schema (e.g. of a database, or file), –depict the structured information (e.g. tables), –specify the layout of those structures (e.g. columns of those tables) –specify the relationships between the structures (e.g. primary keys). 23

24. Steps in modeling Identify entity types Identify attributes Apply naming conventions Identify relationships Apply model patterns Assign relationships Normalize to reduce redundancy (this is called refactoring in software engineering)** Denormalize to improve performance** 24

25. Not just an isolated set of models Handle errors, evolution, … To the physical model? To the logical model? To the conceptual model? Relating to and/ or integrating with other information models? –General rule – integrate at the highest level you can (i.e. more abstract) –Remember the cognitive aspects! (detail) 25

26. Tools for modeling.. Concept mapping - http://cmap.ihmc.us/ http://cmap.ihmc.us/ Models - http://www.datamodel.org/ http://www.datamodel.org/ –MSDN: http://msdn.microsoft.com/en- us/library/bb399249.aspxhttp://msdn.microsoft.com/en- us/library/bb399249.aspx Schema –differs in basic concept from other schema languages –not based on grammars but on finding tree patterns in the parsed document –approach allows many kinds of structures to be represented which are inconvenient and difficult in grammar-based schema languages. –http://www.schematron.com/http://www.schematron.com/ 26

27. More schema tools http://www.w3.org/XML/Schema http://www.stylusstudio.com/xml_schem a.htmlhttp://www.stylusstudio.com/xml_schem a.html http://download.cnet.com/SQL-Schema- Tool/3000-10254_4-10752603.htmlhttp://download.cnet.com/SQL-Schema- Tool/3000-10254_4-10752603.html 27

28. Tools

29. CMAP Ontology Editor (concept mapping tool from IHMC - http://cmap.ihmc.us/coe )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 _softwarehttp://en.wikipedia.org/wiki/List_of_mind_mapping _software White board Piece of paper … you get the idea… 29

30. Review

31. Evaluation Formative (more on this later)

32. These come later Implementation –Technology assessment –Leverage infrastructure –Rapid prototyping Evaluation Open world, iteration

33. Use case!

34. 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

35. 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

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

37. Developed for NASA TIWG 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!

38. 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

39. Actors The initial analysis will often have many human actors Begin to see where these can be replaced with machine actors – may require additional encoding If you are doing this in a team, take steps to ensure that actors know their role and what inputs, outputs and preconditions are expected of them Often, you may be able to ‘run’ the use case (really the model) before you build anything 39

40. Developed for NASA TIWG Actors Real people (round heads) and computers (block heads) E.g. Data provider, end-user, data manager, alert service Primary – initiate (act on) Secondary – respond (acted upon)

41. Developed for NASA TIWG What’s a pre-condition? defines all the conditions that must be true (i.e., describes the state of the system) for the trigger to meaningfully cause the initiation of the use case.

42. Preconditions Often the preconditions are very syntactic and you may not understand how they fit in the implementation Some level of modeling of these preconditions may be required (often this will not be in your first pass encoding which focuses on the main process flow, goal, description, etc.) Beware of using another entities data and services: policies, access rights, registration, and ‘cost’ 42

43. Developed for NASA TIWG Preconditions - data/model

44. Developed for NASA TIWG Preconditions - event/application

45. Developed for NASA TIWG Post-condition? describes what the change in state of the system will be after the use case completes. Post-conditions are guaranteed to be true when the use case ends.

46. Developed for NASA TIWG Success scenarios A re-statement of how the use case via its flows and actors and resources results in achieving the result Describe artifacts produced Describe impacts and metric values

47. Developed for NASA TIWG Failure scenarios A statement of how the use case via its flows and actors and resources did not result in achieving the result Describe role of actors in failure Describe role of resources in failure Describe what artifacts were and were not produced Describe impacts of failure and any metric values

48. Developed for NASA TIWG Normal (process) flows A basis step of (usually) distinct steps that result when the use case is triggers (commences) Steps are often separated by actor intervention or represent modular parts of the flow (can encapsulate activities) Can have loops Should end with the final goal achieved

49. Process flow Each element in the process flow usually denotes a distinct stage in what will need to be implemented Often, actors mediate the process flow Consider the activity diagram (and often a state diagram) as a means to turn the written process flow into a visual one that your experts can review Make sure the artifacts and services have an entry in the resources section This is often the time you may do some searching (no, not soul searching – web searching…) 49

50. Developed for NASA TIWG Alternate (process) flows Variations from the main flow, often invoked by valid but non-usual (or rules) Activity diagrams are useful in representing this part of the document Do not usually represent exceptions/ error flows Can often help to identify general patterns in the use case via similarities with the normal flow While many are possible, usually only include one - illustrative

51. Developed for NASA TIWG Non-Functional requirements (from Wikipedia): Non-functional requirements which specify criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that specify specific behavior or functions. In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be.

52. Developed for NASA TIWG Functional/ non-functional (from Wikipedia): Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are "constraints", "quality attributes", "quality goals" and "quality of service requirements". Qualities, (non-functional requirements), can be divided into two main categories. –Execution qualities, such as security and usability, are observable at run time. –Evolution qualities, such as testability, maintainability, extensibility and scalability, are embodied in the static structure of the software system.

53. Artifacts Add artifacts that the use case generates to the resources list in the table It is often useful to record which artifacts are critical and which are of secondary importance Be thinking of provenance and the way these were produced, i.e. what went into them and produce suitable metadata or annotations Engage the actors to determine the names of these artifacts and who should have responsibility for them (usually you want the actors to have responsibility for evolution) 53

54. Developed for NASA TIWG Resources http://alistair.cockburn.us/index.php/Use_cases,_ten_years_later http://www.digilife.be/quickreferences/pt/functional%20requirements %20and%20use%20cases.pdfhttp://www.digilife.be/quickreferences/pt/functional%20requirements %20and%20use%20cases.pdf http://alistair.cockburn.us/index.php/Resources_for_writing_use_cas eshttp://alistair.cockburn.us/index.php/Resources_for_writing_use_cas es http://alistair.cockburn.us/Usecasesintheoryandpractice180.ppt http://alistair.cockburn.us/Agileusecases1dy.ppt http://alistair.cockburn.us/index.php/Structuring_use_cases_with_go alshttp://alistair.cockburn.us/index.php/Structuring_use_cases_with_go als http://www.foruse.com/publications/bibliographies/usecases.htm http://en.wikipedia.org/wiki/Use_case http://www.ddj.com/dept/architect/184414701 Omnigraffle (Mac) www.omnigroup.com/applications/omnigraffle/ orwww.omnigroup.com/applications/omnigraffle/ Cmap http://cmap.ihmc.us/coehttp://cmap.ihmc.us/coe

55. Questions?

56. Tomorrow Breakouts to work on use cases –Use case scoping and refactoring –Completing / reviewing diagrams –Analysis and information modeling Review use cases

57. 57 Semantic Web Methodology and Technology Development Process Establish and improve a well-defined methodology vision for Semantic Technology based application development Leverage controlled vocabularies, et c. Use Case Small Team, mixed skills Analysis Adopt Technology Approach Leverage Technology Infrastructure Rapid Prototype Open World: Evolve, Iterate, Redesign, Redeploy Use Tools Science/Expert Review & Iteration Develop model/ ontology Evaluation

58. References Twidale, Randall and Bentley (1994) and references therein Scriven (1991, 1996) Weston, Mc Alpine, and Bordonaro, (1995) Worthen, Sanders, and Fitzpatrick, (1997) 58

59. Inventory What categories can you measure? –Users –Files –Databases –Catalogs –Existing UI capabilities (or lack thereof) –Services –Ontologies In the stage of use case development is a very good time to capture these elements; do not guess, get them from quantitative sources or the users/ actors 59

60. Metrics Things you can measure (numerical) Things that are categorical –Could not do before –Faster, more complete, less mistakes, etc. –Wider range of users Measure or estimate the baseline before you start 60

61. Result/ outcome Refer to the use case document Outcome (and value of it) is a combination of data gathering processes, including surveys, interviews, focus groups, document analysis and observations that will yield both qualitative and quantitative results. Did you meet the goal? Just listen… do not defend … if you start to then: QTIP – quit taking it personally 61

62. Example: what we wanted to know about VSTO Evaluation questions are used to determine the degree to which the VSTO enhanced search, access, and use of data for scientific and educational needs and effectively utilized and implemented a template for user-centric utilization of the semantic web methodology. VO – appears to local and integrated and in the end-users language (this is one of the metrics) 62

63. Evaluation (Twidale et al.) An assessment of the overall effectiveness of a piece of software, ideally yielding a numeric measure by which informed cost-benefit analysis of purchasing decisions can be made. An assessment of the degree to which the software fulfils its specification in terms of functionality, speed, size or whatever measures were pre-specified. 63

64. Evaluation An assessment of whether the software fulfils the purpose for which it was intended. An assessment of whether the ideas embodied in the software have been proved to be superior to an alternative, where that alternative is frequently the traditional solution to the problem addressed. An assessment of whether the money allocated to a research project has been productively used, yielding useful generalizeable results. 64

65. Evaluation An assessment of whether the software proves acceptable to the intended end- users. An assessment of whether end-users continue to use it in their normal work. An assessment of where the software fails to perform as desired or as is now seen to be desirable. An assessment of the relative importance of the inadequacies of the software. 65

66. (Orthogonal) Dimensions of evaluations StructuredLess structured QuantitativeQualitative SummativeFormative Controlled experimentsEthnographic observations Formal and rigorousInformal and opportunistic 66

67. Formative and Summative evaluation carried out for two reasons: –grading translations = summative evaluation –giving feedback = formative evaluation 67

68. Formative and Summative 68

69. Evaluation questions and associated data collection methods Evaluation questions: To what extent does VSTO’s Interviews/ Focus Group SurveysDocument Analysis Observation Activities enhance end-user access to and use of data to advance science and education needs? XXXX Activities enable higher levels of semantic capability and interoperability such as explanation, reasoning on rules, and semantic query? XXXX Contribute to the development and support of community resources, virtual observatories and data systems /provision of results from diverse observing systems using semantically- enabled technologies? XXXX 69

70. Evaluation questions and associated data collection methods Evaluation questions: To what extent does X’s Interviews/ Focus Group SurveysDocument Analysis Observation Template contribute to the reports on modern data frameworks, user interfaces, and science progress achieved? XXXX Incorporate user experiences in the redesign and development cycles of the VSTO? XXXX 70

71. Evaluation questions and associated data collection methods Evaluation questions:Interviews/ Focus Group SurveysDocument Analysis Observation How do VSTO activities a ff ect IHE faculty and sta ff from participating institutions (e.g., changes to virtual observatories) and data sources, results from diverse observing systems using sematically-enabled technologies and institutional collaboration activities? XXXX What factors impede or facilitate progress toward VSTO goals? XX What progress has been made toward sustaining and ‘scaling up’ VSTO activities? XXX 71

72. Implementing an evaluation Based on our experience with use case development and refinement, community engagement, and ontology vetting, a workshop format (6 up to 25 participants, depending on desired outcomes and scope) is a very effective mechanism to make rapid progress. The workshops can be part of a larger meeting, stand-alone or partly virtual (via remote telecommunication). We have found (for example, in our data integration work) that domain experts in particular are extremely willing to participate in these workshops. 72

73. Implementing Let’s take an example –VSTO –Representative but does not exercise all semantic web capabilities 73

74. VSTO qualitative results Decreased input requirements: The previous system required the user to provide 8 pieces of input data to generate a query and our system requires 3. Additionally, the three choices are constrained by value restrictions propagated by the reasoning engine. Thus, we have made the workflow more efficient and reduced errors. 74

75. VSTO qualitative results Syntactic query support: The interface generates only syntactically correct queries. The previous interface allowed users to edit the query directly, thus providing multiple opportunities for syntactic errors in the query formation stage. As one user put it: “I used to do one query, get the data and then alter the URL in a way I thought would get me similar data but I rarely succeeded, now I can quickly re-generate the query for new data and always get what I intended”. 75

76. VSTO qualitative results Semantic query support: By using background ontologies and a reasoner, our application has the opportunity to only expose query options that will not generate incoherent queries. Additionally, the interface only exposes options for example in date ranges for which data actually exists. This semantic support did not exist in the previous system. In fact we limited functionality in the old interface to minimize the chances of misleading or semantically incorrect query construction. 76

77. VSTO qualitative results Semantic query support: for example, that a user has increased functionality – i.e., they can now initiate a query by selecting a class of parameter(s). As the query progresses, the sub-classes and/or specific instances of that parameter class are available as the datasets are identified later in the query process. 77

78. VSTO qualitative results Semantic query support: We removed the parameter initiated search in the previous system because only the parameter instances could be chosen (8 different instances to represent neutral temperature, 18 representations of time, etc.) and it was too easy for the wrong one to be chosen, quickly leading to a dead-end query and frustrated user. One user with more than 5 years of CEDAR system experience noted: “Ah, at last, I’ve always wanted to be able to search this way and the way you’ve done it makes so much sense”. 78

79. VSTO qualitative results Semantic integration: Users now depend on the ontologies rather than themselves to know the nuances of the terminologies used in varying data collections. Perhaps more importantly, they also can access information about how data was collected including the operating modes of the instruments used. “The fact that plots come along with the data query is really nice, and that when I selected the data it comes with the correct time parameter” (New graduate student, ~ 1 year of use). 79

80. VSTO qualitative results Semantic integration: The nature of the encoding of time for different instruments means that not only are there 18 different parameter representations but those parameters are sometimes recorded in the prologue entries of the data records, sometimes in the header of the data entry (i.e. as metadata) and sometimes as entries in the data tables themselves. Users had to remember (and maintain codes) to account for numerous combinations. The semantic mediation now provides the level of sensible data integration required. 80

81. VSTO qualitative results Broader range of potential users: VSTO is usable by people who do not have PhD level expertise in all of the domain science areas, thus supporting efforts including interdisciplinary research. The user population consists of: Student (under-graduate, graduate) and non- student (instrument PI, scientists, data managers, professional research associates). 81

82. VSTO quantitative results Broader range of potential users: For CEDAR, students: 168, non-students: 337, for MLSO, students: 50, non- students: 250. In addition 36% and 25% of the users are non-US based (CEDAR – a 57% increase over the last year - and MLSO respectively). The relative percentage of students has increased by ~10% for both groups. 82

83. Adoption (circa 2007) Currently there are on average between 80-90 distinct users authenticated via the portal and issuing 400-450 data requests per day, resulting in data access volumes of 100KB to 210MB per request. In the last year, 100 new users have registered, more than four times the number from the previous year. The users registered last year when the new portal was released, and after the primary community workshop at which the new VSTO system was presented. At that meeting, community agreement was given to transfer operations to the new system and move away from the existing one. 83

84. Facilitating new projects At the community workshop a priority- area was identified which involved the accuracy and consistency of temperature measurements determined from instruments like the Fabry-Perot Interferometer. As a result, we have saw a 44% increase in data requests in that area. We increased the granularity in the related portion of the ontology to facilitate this study. 84

85. Facilitating new projects We focused on improving a users’ ability to find related or supportive data, with which to evaluate the neutral temperatures under investigation. We are seeing an increase (10%) in other neutral temperature data accesses, which we believe is a result of this related need. 85

86. Informal evaluation We conducted an informal user study asking three questions: What do you like about the new searching interface? Are you finding the data you need? What is the single biggest difference? Users were already changing the way they search for and access data. Anecdotal evidence indicated that users are starting to think at the science level of queries, rather than at the former syntactic level. 86

87. Informal evaluation For example, instead of telling a student to enter a particular instrument and date/time range and see what they get, they are able to explore physical quantities of interest at relevant epochs where these quantities go to extreme values, such as auroral brightness at a time of high solar activity (which leads to spectacular auroral phenomena). This suggested to us some new use cases to support even greater semantic mediation 87

88. Further measuring One measure that we hoped to achieve is to have usage by all levels of domain scientist – from the PI to the early level graduate student. Anecdotal evidence shows this is happening and self classification also confirms the distribution. A scientist doing model/observational comparisons: noted “took me two passes now, I get it right away”, “nice to have quarter of the options”, and “I am getting closer to 1 query to 1 data retrieval, that’s nice”. 88

89. Focus group A one hour workshop was held at the annual community meeting on the day after the main plenary presentation for VSTO. The workshop was very well attended with 35 diverse participants (25 were expected) ranging from a number senior researchers, junior researchers, post-doctoral fellows and students - including 3 that had just started in the field. After some self-introductions eight questions were posed and responses recorded, some by count (yes/no) or comment. Overall responses ranged from 5 to 35 per question. 89

90. VSTO quantitative results How do you like to search for data? Browse, type a query, visual? Responses: 10; Browse=7, Type=0, Visual=3. What other concepts are you interested in using for search, e.g. time of high solar activity, campaign, feature, phenomenon, others? Responses: 5; all of these, no others were suggested. Does the interface and its services deliver the functionality, speed, flexibility you require? Responses: 30; Yes=30, No=0. 90

91. VSTO quantitative results Are you finding the data you need? Responses: 35; Yes=34, No=1. How often do you use the interface in your normal work? Responses: 19; Daily=13, Monthly=4, Longer=2. Are there places where the interface/ services fail to perform as desired? Responses: 5; Yes=1, No=4. 91

92. Qualitative questions What do you like about the new searching interface? Responses: 9. What is the single biggest difference? Responses: 8. The general answers were as follows: –Less clicks to data (lots) –Auto identification and retrieval of independent variables (lots) –Faster (lots) –Seems to converge faster (few) 92

93. Unsolicited/ unstructured comments It makes sense now! [I] Like the plotting. Finding instruments I never knew about. Descriptions are very handy. What else can you add? How about a python interface [to the services]? 93

94. Surprise! New use cases The need for a programming/ script level interface, i.e. building on the services interfaces; in Python, Perl, C, Ruby, Tcl, and 3 others. Addition of models alongside observational data, i.e. find data from observations/ models that are comparable and/or compatible. More services (particularly plotting options - e.g. coordinate transformation - that are hard to add without detailed knowledge of the data). 94

95. Keep in mind You need an evaluation plan that can lead to improvements in what you have built You need an evaluation to value what you have built You need an evaluation as part of a publication 95

96. Iterating Evolve, iterate, re-design, re-deploy –Small fixes –Full team must be briefed on the evaluation results and implications –Decide what to do about the new use cases, or if the goal is not met –Determine what knowledge engineering is required and who will do it (often participants in the evaluation may become domain experts in your methodology) –Determine what new knowledge representation –Assess need for an architectural re-design 96

97. Summary Project evaluation has many attributes Structured and less-structured Really need to be open to all forms A good way to start is to get members of your team to do peer evaluation This is a professional exercise, treat it that way at all times Other possible techniques for moving forward on evolving the design, what to focus upon, priorities, etc.: SWOT, Porter’s 5 forces 97

98. 98 Semantic Web Methodology and Technology Development Process Establish and improve a well-defined methodology vision for Semantic Technology based application development Leverage controlled vocabularies, et c. Use Case Small Team, mixed skills Analysis Adopt Technology Approach Leverage Technology Infrastructure Rapid Prototype Open World: Evolve, Iterate, Redesign, Redeploy Use Tools Science/Expert Review & Iteration Develop model/ ontology Evaluation

99. 99 Implementation Basics Review your use case with team and experts Go into detail of your ontology; test it using the tools you have We will look at the use case document and examine the actors, process flow, artifacts, etc. You will start to develop a design and an architecture Keep in mind that it is more flexible to place the formal semantics within your interfaces, i.e. between layers and components in your architecture or between ‘users’ and ‘information’ to mediate the exchange

100. Actors The initial analysis will often have many human actors Look to see where the human actors can be replaced with machine actors – many will require additional semantics, i.e. knowledge encoding If you are doing this in a team, take steps to ensure that actors know their role and what inputs, outputs and preconditions are expected Often, you may be able to ‘run’ the use case (really the model) before you build anything 100

101. Process flow Each element in the process flow usually denotes a distinct stage in what will need to be implemented Often, actors mediate the process flow Consider the activity diagram (and often a state diagram) as a means to turn the written process flow into a visual one that your experts can review Make sure the artifacts and services have an entry in the resources section 101

102. Preconditions Often the preconditions are very syntactic and may not be ready to fit with your semantically-rich implementation Some level of modeling of these preconditions may be required (often this will not be in your first-pass knowledge encoding, which focuses on the main process flow, i.e. goal, description, etc.) Beware of using other entities data and services: e.g., policies, access rights, registration, and ‘cost’ 102

103. Artifacts Add artifacts that the use case generates to the resources list in the table It is often useful to record which artifacts are critical and which are of secondary importance Be thinking of provenance and the way these artifacts were produced, i.e. what semantics went into them use this information to produce suitable metadata or annotations Engage the actors to determine the names of these artifacts and who should have responsibility for them (usually you want the actors to have responsibility for evolution) 103

104. Reviewing the resources Apart from the artifacts and actor resources, you may find gaps Your knowledge encoding is also a resource, make it a first class citizen, i.e. give it a namespace and a URI Often, a test-bed with local data is very useful at the start the implementation process, i.e. pull the data, maybe even implement their service (database, etc.) 104

105. Back to the knowledge encoding Declarative: in CL, OWL (probably OWL-DL), RDF, SKOS? Need rules? Need query? Science expert review and iteration Means you need something that they can review, with precise names, properties, relations, etc. The knowledge engineering stage is much like a software engineering process 105

106. Knowledge engineering The interplay between tools like Protégé and CMAP will be very important in implementing a knowledge base that has ‘just enough’ 106

107. Summary By now, the reality of going into complete detail for the knowledge representation should be apparent Keeping it simple is also very important as you begin to implement Being prepared to iterate is essential Now is the time to validate your ontology with domain experts and your team, use the tools The next stage is to choose your technology components and build and test 107

108. Back shed

109. 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)

110. 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)

111. (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

112. 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)

113. 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).

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

115. 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

116. Credit: B. Rouse (BEVO) 2008

119. 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)

120. 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 1 st ….

121. (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’

122. Scale free?

123. (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

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

125. What about meaning? Sustained? Evolved? Named and typed relationships

126. And more…

127. (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