1. 1 Class exercise II: Use Case Implementation Deborah McGuinness and Peter Fox CSCI-6962-01 Week 8, October 20, 2008

2. Contents Review of use case presentations, questions, comments Implementing a use case – this is where it can get tough and complicated for semantics Summary Next week 2

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

4. 4 Implementation Basics Review your documented 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 (more on architecture and middleware next week) Keep in mind that it is more flexible to place the formal semantics between/ in your interfaces, i.e. between layers and components in your architecture, i.e. between ‘users’ and ‘information’ to mediate the exchange

5. Actors The initial analysis will often have many human actors Begin to see where these can be replaced with machine actors – may 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 of them Often, you may be able to ‘run’ the use case (really the model) before you build anything 5

6. 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 Often the time you may do some searching 6

7. 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, goal, description, etc.) Beware of using other entities data and services: policies, access rights, registration, and ‘cost’ 7

8. 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 semantics 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) 8

9. 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 Sometimes, a test-bed with local data is very useful as you start the implementation process, i.e. pull the data, maybe even implement their service (database, etc.) 9

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

11. Knowledge engineering Classes 2, 3, 5 and 6 Mostly choose OWL-DL (and OWL 2) We may need to go to OWL 2 for numerical comparisons and if so, separate your owl 1 from OWL 2 representations The interplay between tools like Protégé and CMAP will be very important in implementing a knowledge base that has ‘just enough’ 11

12. 12 Implementation Basics Review documented use case now Go into detail of the ontology Now we will look at the use case document and examine the actors, process flow, artifacts, etc. Start thinking of a design and an architecture Semantics between/ in your interfaces

13. Implementing Let’s take a few examples –VSTO –Atmosphere/Volcano, Sensor web –Another 13

14. Roles and skill-sets Facilitator – changes slightly for implementation - sometime the facilitator becomes chief architect, sometimes steps back Domain experts are needed for expert review (domain literate, know resources; data, applications, tools, etc) You are the modeler (to extract objects, triples) You are likely to play the role of a software engineer (architecture, technology) but you can also ask someone for help with this Document, document, document It is social – a team effort

15. Use case roles and skill-sets Time for a self assessment We will scope for the purpose of learning how to …

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

17. Next week This weeks assignment: –reading: IAAI VSTO, Semantic eScience Web Services and C&G paper Next class (week 9 – October 27): –Foundations V: Infrastructure and Architecture, Middleware Questions? 17

18. Formal Use Case Description Use Case Identification Revision Information Definition Successful Outcomes Failure Outcomes

19. Developed for NASA TIWG Use Case Elaboration Actors –Primary ActorsPrimary Actors –Other ActorsOther Actors Preconditions Postconditions Normal Flow (Process Model) Alternative Flows Special Functional Requirements Extension Points