aka - ESIP Wiki

Download Report

Transcript aka - ESIP Wiki

ESIP Semantic Web Products and
Services ‘triples’ “tutorial”
aka sausage making
ESIP SW Cluster, Jan 6 2011
http://wiki.esipfed.org/index.php/Testb
ed
See also
http://wiki.esipfed.org/index.php/Sema
ntic_Web_Tutorials
Why and What
• Wed PM Session 1
– Introduction – 10 mins – Peter
– Use case – motivation and scope – 20 mins - Chris
– Model – based on use case, start with domain model and proceed
to ontology model and then show them how to engineer it (i.e. a
piece of it) – 1 hr – Peter and Rob
• Wed PM Session 2
– Model ctd – 20 mins – Peter and Rob
– Instance generation and population (how to? Write turtle, use
Protégé, …), triple store ingest, web form – demo – 1 hr – Peter
– Summary and evaluation – 10 mins –Hook
What and how
• Thu AM Session 3
– Intro to these sessions – 10 min - Peter
– Application definition – decompose use case, review technology and
dependencies, examine requirements for search and report, add/ correct
instances, technology dependencies – 30 mins – Peter
– Evaluation –10 mins - Hook
• Thu AM Session 4
– Query development – query introduction, SPARQL tutorial, generate SPARQL,
follow along, provide a web query form, cut paste query into a textbox and
execute and get result, for visual or text traversal - 1hr – Hook
– Evaluation –10 mins - Hook
• Items that would lead into intermediate (next) tutorial – 20 mins
Application definition
• Means examine the use case
• Scope the first iteration
• Useful to think about metrics and record
baselines (if they exist)
Implementation Basics
• Review your use case with team and experts
• Go into detail of your ontology; test it using the
tools you have
• Look at the use case document and examine the
actors, process flow, artifacts, etc.
• 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
5
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
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 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, i.e. goal, description, etc.)
• Beware of using other entities data and
services: e.g., policies, access rights,
registration, and ‘cost’
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
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) 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
• 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.)
10
Back to the knowledge encoding
• Declarative: OWL, RDFS, 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
11
Chris: Sample Queries
• Which projects are working with semantic
web technology?
• What technologies are being used in NASA’s
ACCESS program?
• Are any projects working with the same
dataset?
• Which datasets are being used in projects
working with semantic web?
Use Case 1: Enter Project Data (cont.)
1. Use Case 1: Enter Project Data
2. Short Definition
Someone from the project is assigned to
populate the triple store with the project
information. This capability is supplied via a
simple Web interface.
3. Primary Actor: Project staff member
4. Purpose: Enter project information into the
triple store.
5. Assumptions: The staff member knows enough
about his/her project to populate the fields
Use Case 1: Enter Project Data
6.
Scenario
1.
2.
3.
4.
5.
6.
7.
8.
9.
7.
Interface asks for overall project information: name and program
User enters basic project information
Web interface saves root project triple
User selects Add Staff and Web interface presents existing staff, plus blank for staff not yet in triple store
User selects existing staff and possible role, and Web interface saves triples linking staff to project
User selects Add Technology and Web interface presents existing technologies, plus blank for
technologies not yet in triple store
User selects existing technology, and Web interface saves triples linking technology to project
User selects Add Datasets and Web interface presents existing datasets, plus blank for datasets not yet in
triple store
User selects existing dataset, and Web interface saves triples linking technology to project
Extensions
5b.
7b.
9b.
User enters new staff and picks existing role and Web interface saves triples linking staff to project
User enters new technology and Web interface saves triples linking technology to project
User enters new dataset and Web interface saves triples linking dataset to project
8. Definition of success: triples are added to the database
So, recall – our first iteration
• So that we can rapid prototype, instead of
implementing an ‘interface’ as defined in the
“add record”
• We generated a set of instances (i.e. partial or
complete record)
• Who tried it?
• How did it work/ not?
Second iteration
• Implementing an ‘interface’ as defined in the
“add record”, to generate instances
• Let’s talk about what they may look like
What’s next …
Use Case 2: Produce Program
Technology Inventory
1. Use Case 2: Produce Program Technology
Inventory
2. Short Definition
An agency program manager gets a report on
what technologies are being used in his
program.
3. Primary Actor: Agency program manager
4. Purpose: Get a report on technology usage for
planning purposes (or occasional “fire drill”).
5. Assumptions: The program’s projects have
been entered into the triple store
Produce Technology Inventory, cont.
6. Scenario
1.
2.
User pulls up Technology Inventory Report and selects from available
programs.
Web Interface queries triple store for technologies used by projects within
the select program and generates a report.
7. Extensions: None
8. Definition of success: Program Manager gets a formatted list
of which projects are using which technologies within his /
her program.
9. Notes: This scenario is not uncommon, particularly for new
technologies.