Review of semantic annotation proposals

From Semantic Sensor Network Incubator Group
Revision as of 06:35, 19 January 2011 by Llefort (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

XLink referencing named individuals

In the next three next references, XLink @href is generally used within a property GML element (starting with a lower case letter) to create a link to an individual (this is a correct use of XLink). In some cases, the link points to an element which is or could be managed in an ontology if an appropriate URN redirection mechanism was set up.

Sheth (2009):

Bermudez (2009):


New types of semantic Annotations (Sapience)

Janowicz et al. also use xlink:href to point to an individual (we assume Anemometer01 and WindDirection are individuals). It is interesting to note the presence of an xlink:role attribute (which should be an xlink:arcrole) pointing to sawsdl:modelreference. This suggests that a SAWSDL-based approach could be used in such a case, although there is no reference to a required lifting script in the paper. The last example should not be interpreted as a semantic annotation.

Janowicz (2009):

Sapience is a free and open source API for semantic annotations. It consists of several Java libraries to control the lookup and injection of reference links into predefined metadata. Service developers can forward their serialized XML document to Sapience which then adds the appropriate links into the provided documents and returns the new versions to the source application. The annotations instructions are stored and looked up in a database - Sapience does not support the authoring of annotations so far. Once a (feature type) schema, as well as the external references to a global ontology are generated and uploaded by the service developer Sapience can add semantic annotations to the service and hence provide Semantic Enablement [1]. So far, Sapience is mostly focused on the annotation geospatial data compliant with the Open Geospatial Consortium (OGC) standards and especially for KML.

+ Note: preliminary review of Sapience and its use of annotation attributes like modelReference and domainReference [2]

Sapience supports the dynamic and standard-compliant injection of references to external shared vocabularies into (meta)-data (Maue) and SAWSDL-like model reference to XML schema.

Three types of annotation properties can be used (see also Listing 1, 10, 11, 13 in OGC 08-167r1 and the [Annotation ontology):

  • modelReference reuse (or extends?) the SAWSDL standards
  • domainReference and measureReference are new types of annotations:
    • domainReference handles the relation to the domain model, a "relation for connecting elements of a resource ontology with domain ontologies" and "supports information retrieval tasks". It may be related to the corresponding usage in WSML (see Listing 1 in OGC 08-167r1)
    • measureReference handles the relation to the reference space, a "relation for connecting attributes of a resource ontology, like FTOs, with semantic datums for attributes"

Maue, Schade, et al. (2009):

Geographic Information on the Internet] Toulouse April 2009 (pp 71-76)

The documentation includes the description of two distinct use cases for Sapience

The tutorial and java libraries are directed at users of KML. The WSDL module is at an earlier phase of development (initial upload of source code to the Subversion repository)

In Sapience, the injection is the process of adding references to external supplementary documentation to local metadata. The page describing the Injection Procedure does not say if the injection step only corresponds to the addition of annotations in the same format (e.g. XML) or if it also covers the lifting step (as in SAWSDL's definition of "lifting"). This example, Generating OWL instances from the feature/annotation model and apply SWRL spatial built-ins suggests that the lifting operation would allow to exploit the added semantics (e.g. the spatial relations) with the help of SWRL rules (or equivalent).

Note: analysis to be completed

  • sawsdl:modelReference originates with the SAPIENCE project. + Note: sawsdl:modelReference comes from Section 2.1 of the SAWSDL specification [17]
  • Maue 2009 [3] (pp 71-76) defines the difference between a modelReference and a domainReference annotation *see below).

Maue (2009): Semantic annotations establish twofold links. First, the Model Reference links from the schema-based data model to the local Resource Ontology which can be interpreted by query processing algorithms. This ensures that semantic annotations can be applied to all kinds of geospatial resources, as long as we are able to map from the data model to the resource ontology. The Domain Reference relates the local concepts to global domain ontologies capturing the common vocabulary within one community. It is usually based on rules which properly reflect the inner relationships of the data model.

(see also slide 61 in [4])

+Open issue (20100114 Laurent_Lefort): there is an assumption in SAPIENCE that a two-step mapping annotation mechanism (schema to ontology and then local (resource ontology) to global reference (domain ontology)) is used. The question here is whether the proposed mechanism should also covers cases the annotation is done in a single step (which I think is what SAWSDL was developed for). Could we have a specification which says that we can chain these properties with an axiom like: sapience:modeReference o sapience:modelreference sub-property-of sawsdl:modelReference

  • question: Is this related to the definition of mapping rules in the WSML community? (if yes, reference to add - but I have a suspicion the answer is no)

+Note: evaluate the terms defined in Appendix A Glossary of OGC Discussion Paper "Semantic Annotations in OGC Standards OGC 08-167r1

  • Annotation: Attaching descriptive metadata to a resource, with the intention to simplify its discovery and evaluation.
  • Model reference: A link between an element in the schema-based metadata and a concept in the → knowledge model. The model reference is used to link to an entity with equivalent semantics but a different encoding.

Use of URNs

There is a range of OGC documentation on how to manage URNs but it is difficult to map these best practice guidelines with the corresponding Semantic Web best practice guidelines. One issue is that there is not yet "reference" implementations of URN resolvers which bridge the gap between the two worlds.

URNs can theoretically be mapped to the three possible types of ontology/vocabulary definitions: classes, properties or individuals. In general, they correspond to individuals/instances (e.g in the EPSG registry).

Issue:

  • is there anything in the OGC specifications which limit the use of URNs to named instances?
    • No: a URN (like any other kind of URI) identifies a _resource_. The kind of resource depends on the context: so, the next question is what are the different context in which a URN may be used
  • Should OGC specifications be improved to define the different types of context for the different type s of URNs and enable more robust validation mechanisms (when the URN is mapped to a semantic web definition, it is possible to know if it corresponds to a class, a property or an individual).

Here are some examples to help us to identify different contexts (Note: there is a convention followed in GML schemas which is less rigorously applied in SWE and SensorML - It is important to identify the request for changes issued to fix those discrepancies).

@definition in swe:Quantity:

swe:Quantity (SensorML):

 <swe:Quantity definition="urn:ogc:def:property:SBE:batteryCurrent">

@definition: Points to semantics information defining the precise nature of the component (from xsd via [5])

This looks like the reference to an ObjectProperty in OWL:

@uom

Example 1: SensorML tutorial [6] (OGC-member-only) or [7]

<Quantity definition=“urn:ogc:def:phenomenon:temperature” uom=“urn:ogc:def:unit:celsius”/>

Expectation that the URN would match an individual.

Note: uom is a special case in OGC schemas - for concision and convenience, it appears as an attribute so it is not easily possible to annotate it specifically if we only have a generic mechanism for XML elements.

@xlink:href in Process

Example 1: SensorML tutorial [8]

 <process name="thermometer" xlink:href="urn:vast:sensor:davisTemperature:1.0:001"/>

Should be Process element instead of process?

Expectation that the URN would match an individual.

@definition in sml:Term and text() in sml:value:

Example 1 (MMI [9]):

 <sml:Term definition="urn:x-ogc:def:identifier:OGC:uuid">
  <sml:value>urn:x-ogc:object:sensor:MBARI:GPS:17:HVS</sml:value>
 </sml:Term>

Example 2 (52North [10]):

 <sml:Term definition="urn:ogc:def:identifier:OGC:uniqueID">
   <sml:value>urn:ogc:object:feature:Sensor:IFGI:ifgi-sensor-3</sml:value>
 </sml:Term>

Example 3 (IOOS [11])

<sml:Term definition="urn:x-noaa:def:classifier:NOAA::stationType">
  <sml:codeSpace xlink:href="http://www.ndbc.noaa.gov/mooredbuoy.shtml"/>
  <sml:value>6-meter NOMAD buoy</sml:value>
</sml:Term>

Example 4: (SensorML/Alexandre Robin, 2007 [1])

 <sml:Term
     definition="urn:x-ogc:def:classifier:OGC:sensorType">
     <sml:codeSpace
       xlink:href="urn:x-ogc:dictionary:OGC:sensorTypeTaxonomy"/>
     <sml:value>RADAR</sml:value>
  </sml:Term>

Example 5: (Luis Bermudez, public-xg-ssn 2009 [12])

 <sml:Term definition="http://www.w3.org/1999/02/22-rdf-syntax-ns#type">
   <sml:value>http://mmisw.org/mmi/20080529/sensor.owl#CTD</sml:value>
 </sml:Term>

The convention here is that the @definition points to an ObjectProperty (but maybe it can also be DatatypeProperty) and the value contains an indiviudal or a literal.

@xlink:href in sml:codeSpace

Example 3 (IOOS [13])

 <sml:codeSpace xlink:href="http://www.ndbc.noaa.gov/mooredbuoy.shtml"/>

Example 4: (SensorML/Alexandre Robin, 2007 [1])

 <sml:codeSpace xlink:href="urn:x-ogc:dictionary:OGC:sensorTypeTaxonomy"/>

The two examples above are not comparable but it is possible to infer from them that the use of xlink:href in the "codespace context" may differ from other context.

@xlink:role (?) in swe:field: same issue

Ex of a property URN (here, it is not clear if @arcrole should be used instead):

 <swe:field name="Battery Current“ xlink:role="urn:ogc:def:property:powerSupply">

@srsName pointing a URN:

 <gml:pos srsName="urn:epsg:crs:28353">681426 6630902</gml:pos>

GML spec. (Wikipedia) [14] The value of the srsName attribute is a Uniform Resource Identifier (URI). It refers to a definition of the Coordinate Reference System that is used to interpret the coordinates in the geometry. The CRS definition may be in a document (i.e. a flat file) or in an online web service.

Usage of @href (to an individual) generally correct.

Dual use of URNs

The community developing and using OGC standard plans to use SKOS to manage vocabulary elements. This evolution will lead to situations where non-semantically augmented OGC files will contain references to URNs (which correspond to SKOS concepts or even the "cool URIs" of this concepts) in any of the contexts discussed above.

The issue here is "is there a risk of clash between this usage and the added semantic annotations"?

Tentative use of RDFa

Barnaghi et al (2009) is a tentative to add semantic annotations to a SWE-based example which uses a syntax which is somewhat intermediate between what's used in OWL and in RDFa (see comments below).

  • Barnaghi et al. Sense and Sens'ability: Semantic Data Modelling for Sensor Networks, in Proc. of the ICT Mobile Summit 2009, June 2009.
    • SWE’s @definition mapped to class
    • OWL-like attribute namespaces (non ok)
    • @about mapped to individual (ok)
    • @datatype mapped to xsd type (ok)
    • @resource used but without corresponding @property
    • @ID used (not ok)
    • URI conventions (not ok)