OGC Architecture gaps

Architecture working group GeoSciML meeting

Edinburgh 2011

W_S

Components

Vocab

FeatureCatalog

Metadata

WMS

WFS

SOS

Model

Ontology

Mapping

ExpansionReasoning

Archipelago of Fullmoon

UML

XSDRDFS

Servicia

HTTP bay VocabulariaPeninsula of SKOS

SPARQLcrossing

Desert of OWLDesert of OWL

Ishme of mapping

Bottomless Bay of metadata

Catalog island

WMS peninsula

WFS jungle

SOS swamps

WMC harbour

HMS GeoSciML III

Island ofportrayal

Ocean of One Geology

Sea of schematron

Valid

atio

n st

raig

ht

Capab

ilitie

s stra

ight

19115 Island

HMCS GWML

Soft-typingquicksands

HMAS ERML

REST reef

Persista

nt URI r

ange

Ontologymoat

EBRim bay

RIFbay

broaderThan

narrow

Sea of nillables

GML cliffO&M beach

SWE hill

OG Sea

urgh

OGC Gaps with community schemas

How to provides vocabularies (vocab services and mapping)

How to document properties Complex value metadata Vocabulary

How to stitch services together into an application (WMS / WFS / **S)

Vocabularies Delft meeting

Discussion about Ontologies and vocabularies Mapping across vocabularies

USGS constrains. They have legal binding for using a specific vocab.

OWL over SKOS (because OWL allows reasoning)

Creating a WG ?

How to expose semantic info Schema (service registry) Domain of values Mappings Governance: responsibilities Need one standard way of exposing

semantic info

Slides from Delft HDWG meeting

Action Items - 1 Harmonization report? Here are a few interesting efforts:

BODC (British Oceanic Data Center ?) has done review of options for vocab services – extend it

French geol survey with INSPIRE Bureau Of Meteorology : WaterML and Geosciences

vocab services Model registry (Rob) Linked Open Data (they have really interesting stuff) Mediator in GWIE (à la GEON) CUAHSI ontology work

--------------- Figure out common patterns and gaps Get OGC mandate to do it (geosemanticsWG?)

Slides from Delft HDWG meeting

Action Items - 2 Report it as a current problem with OGC

architecture NGA interested?

Cross-domain; water security; situation awareness JeremyT

Would OGC be interested in finding sponsors for an effort to fill this gap in architecture

White paper: Use cases; common issues; common gaps

Get on IE agendas

Slides from Delft HDWG meeting

Property Binding Goals

Initiated from GWIE It’s beyond « GeoSciML » The XSD and Schematron rule are good to

check after the fact but we can’t deduce all the « possible values » to create GUI

Vocab informations are externalised and we need a way to « bind » this property to that vocabulary.

Property binding Use Case Client application is provided a WxS URL, which is used to extract the

service GetCapabilities. The client application parses the capability files and depending of the

service type, spawns a user interface Client application provides the user with a list of queryable feature

types Users picks a feature type Client application invokes "DescribeFeatureType" to the service and

extract a schema Client application then shows an interface where the user can build a

filter , The user is provided with a GUI where at some point he can build a reference to a property

The user builds a property path by progressively navigating the model Once the user reachs a literal property, it allows the user to enter a value

If the value must come from a vocabulary, the client application provided a way to browse through the list of possible terms.

If the value is schema constrained (with a pattern), the application can provide either post-entry validation, or more advanced components (such as a calendar tool)

Once the filter is completed, the client application can use the filter to interact with the service.

Issues with community schemas

How do we access a complete schema? If the feature has subtypes in another schemas, how can I be sure to know about them.

How do we bind a vocabulary to a property? How do we store this binding How do we parse the vocabulary (how can we know the

format) What literal is used when referring a vocabulary term? How we write a filter over a property that can be of several

possible types (either because of polymorphism or <<Union>>)?

How can we infer unit of measurement?

Two aspects Property metadata

How we document property (uom, term list, semantic)

Property reference How do we identify a property ? Is this enough ?

Complex value Try not to change WFS operation Let « old » client work

« new » client ingests new information Externalise the solution Use existing technology

Schema Requirement 1. All operations that return a community schema shall only

return references (import statements) to the original locations of community schemas.

Requirement 2. A schema describing a queryable resource must include all relevant xsd:import to allow discovery of all queryable extensions of the exposed resource.

Requirement 3. Import statement shall use absolute paths. Recommendation 1. When a specific type is requested, all sub types from

another namespace should be casted using xsi:type to the namespace of the request type.

Property reference

An example from GeoSciML is the lithology property that is bounded to a vocabulary. The vocabulary used in the context of a map :

(MappedFeature/specification/GeologicUnit/composition/CompositionPart/material/RockMaterial/lithology)

can be different from the same property in a borehole context :

(Borehole/MappedInterval/specification/ GeologicUnit/composition/CompositionPart/material/RockMaterial/lithology)

Property reference Requirement 4. Reference to property must be expressed using

the service location, the method, and the context type following the syntax {serviceURL}/{Method}/{contextFeature}/{path}

Requirement 5. When a property reference might contain substitution, the path shall use '*' in place of substitutable elements

Requirement 6. When more than one reference property matches a target path, the reference with the less degree of freedom shall be used.

Requirement 7 : A property that refers to a feature shall accept xlink:href syntax to represent this association

Requirement 8. Property metadata shall be expressed in SWECommon

Requirement 9. Property metadata shall have a mandatory identifier

Requirement 10. Property metadata shall use HTTP URI as unique identifier

Property reference Recommendation 2. property that links a property to a SWE description

shall be named ogc:propertyMetadata Recommendation 3. inverseOf ogc:propertyMetadata shall be ogc:property

<rdf:Description rdf:about="property reference URI"><ogc:propertyMetadata rdf:resource="property metadata URI"/>

</rdf:Description>

Data record

<swe:DataRecord name="waterRecord"><swe:field name="phenomenonTime">

<swe:Time definition="urn:ogc:data:time:iso8601"><swe:uom xlink:href="http://www.52north.org/units.xml#milliseconds"/>

</swe:Time></swe:field><swe:field name="waterlevel">

<swe:Quantity definition="urn:ogc:def:phenomenon:OGC:1.0.30:waterlevel"><swe:uom xlink:href="http://www.52north.org/units.xml#meter"/>

</swe:Quantity></swe:field><swe:field name="flowrate">

<swe:Category definition="urn:ogc:def:phenomenon:OGC:1.0.30:flowrate"><swe:codeSpace xlink:href="http://www.52north.org/codeSpaces/flowrateCategories"/>

</swe:Category></swe:field>

</swe:DataRecord>

Date record Requirement 11. Complex value shall be expressed in valid

swe:Record Requirement 12. A reference to a DataRecord component shall be

expressed using field names as proxies for literal path Requirement 13. The filter shall always target the XML encoding Requirement 14. When a service realises that an inadequate

vocabulary has been used, it shall raise an exception Requirement 15. An error following the usage of the wrong

dictionary shall identify the faulty dictionary and the property path used in the filter.

Recommendation 4. A compliant service shall have an extension in their GetCapabilities where dictionary reference are explicitly listed.

Requirement 15: Vocabulary shall be available in RDF representation

Requirement 17: Each term shall be identified by a HTTP URI Recommendation 5. Vocabulary should be available in SKOS.

Data record Requirement 18: Term used in the filter shall be the full HTTP URI of the

term Requirement 19: Property that are controlled by a vocabulary shall be

documented by a swe:Category Requirement 20: Category swe:identifier shall be a unique identifier for this

vocabulary mapping Requirement 21: swe:codeSpace shall be a reference to the SKOS

collection

<swe:Category definition="http://sweet.jpl.nasa.gov/2.0/Geology.owl#EarthMaterial"> <swe:identifier>http://ngwd-bdnes.cits.nrcan.gc.ca/Reference/uri-cgi/classifier/ca.on/Vocabulary/OntarioWaterWellLithologies</swe:identifier> <swe:label>Ontario lithologic vocabulary</swe:label> <swe:description>List of lithologic terms use in their water well database</swe:description> <swe:codeSpace xlink:href="http://ngwd-bdnes.cits.nrcan.gc.ca/Reference/uri-cgi/classifier/ca.on/lithology/442"/></swe:Category>

Remaining issues Ordinal terms Complex knowledge Rob,Boyan and now Simon (in unison) :

Ontology reasoning (and query expansion)

OWS Context

OGC® OWS-7 Information Sharing Engineering Report OGC 10-035r2 WMC (Web Map Context) in steroid Based on Atom (RSS type of file) Pointed to by D. Arctur when we whined about WMS / WFS /

SOS binding in GWIE Ongoing (can be influenced ?)

Different implementations 1G is « client knows »

Specific client that reads from the catalog and redirects GFI to information service

GSML TB 3 « client knows » Specific client knows where the get the WFS

URL in the capabilities document. GIN « mediator knows »

Mediator wraps WMS service and intercepts requests

OWS Context The principle use case for an OWS Context

document is for defining the application application statestate of an Integrated Client. When this application state is reproduced by two or more Integrated Clients, such clients are said to share a common operational picture.

Collection of Resources

Vocabulary ?

Context UML (as for 5 hrs ago)