Warning:
This wiki has been archived and is now read-only.

SSN Tasks

From Spatial Data on the Web Working Group
Jump to: navigation, search
  1. Check and reconsider/redesign modularisation of SSN into patterns
    1. Clearly separate observation, sensor, and deployment parts.
    2. Disentangle SSN from DUL (this may require adding things to SSN that are needed from DUL)
    3. Reconsider O&M alignment (see O&Mlite) - as alternative to DUL?
    4. Provide deeper OWL axiomatization (now that DUL is gone) - kjanowicz to explain
    5. See proposal in charter: noting the work to split the ontology into smaller sections to offer simplified access.
  2. Align with Prov-o
  3. Discuss potential need of rdf datacube alignment (pre-Coverage work)
  4. Extend to cover UCRs and/or wish list items
    1. What goes in SSN and what should be a recommended profile/extract/extension (use kjanowicz's analysis of literature)?
    2. Develop targeted versions/profiles/extracts/extensions (e.g. Wot? Iot-lite? satelite sensors? samples? human sensors? advise how to do this?
    3. Re-consider actuation with WoT
    4. Sampling features - specimens and sites - as described in several of the submitted use-cases, esp Marine Observations
  5. Revisit annotation properties, including multilingual
  6. Transfer/link/align common issues with BP and UCR deliverables.
  7. Write the specs (in what form?)
  8. Write primer, drawing on SSN in the wild, and worked examples (reuse SSN-XG doc) (I am thinking this is a parallel process -- all activities include contributing this kind of documentation).


Tools for ontology editing

What should we use?

Tool Name Repository Serialization supported Predictable Serialization OWL2 support
Protégé Github can be used RDF/XML, Turtle etc. No, initially alphabetical, but if class/property is renamed, it is not re-sorted, but remains in the initial position Yes
WebProtégé Cloud storage RDF/XML, Turtle etc. No, new or edited classes are added to the beginning of the class section serialization without any discernible logic Yes, full OWL2 support now through the "OWL Entity Description Editor", a text-based editing tool that can be added as a tab
Vocol https://github.com/vocol/vocol Github Turtle Yes, as you directly edit the source file on Github. Syntax coloring, but no graphical user interface for editing classes/properties/instances. Yes, full OWL2 support (syntactically)
TopBraid Composer Free Edition Github is directly supported RDF/XML, N-Triples, Turtle, JSON-LD Consistent alphabetical ordering in TTL file (recommended) OWL2-RL is built in

Modularisation topic

Error creating thumbnail: Unable to save thumbnail to destination
SSN modularisation sketch (cc-by Kerry Taylor)

This is the modularisation done by Michael Compton, mentioned in the charter [1]

For comparison, here is the SSN architecture sketch

And here is a concept diagram view (attribute to Stapleton, Howse, Delaney) [ page 105 http://www.ontologyengineering.org/sites/default/files/OntologyEngineeringWithDiagramsV1-1.pdf]

SSN modularisation sketch (cc-by Kerry Taylor)

This is an attempt to describe pictorially what we decided in the meeting 9/2/2016

And in the link you can find an analysis of the current SSN conceptual modules.



























Why move ssn:Sensor class from dul:physicalObject to dul:Object

  1. Because a sensor was always meant to include computational methods -- see the English annotation description
  2. Because some people think that a "physical object" cannot include a computational method (others disagree)
  3. Because a dul:Object is the disjoint union of a dul:physicalObject and a dul:socialObject (which most certainly can include a computational algorithm), so if it is a direct class of a dul:Object you can still have it either way for any particular sensor.
  4. Because the impact on existing implementations is likely to be very small or non-existent (due to going *up* one level)-- and there is no conflict at all with some extension class of sensors being all physical objects --although one more axiom would be needed to force that).
  5. Because I have done a check on the behaviour with a reasoner and I can find no difference.

See 2 images showing this (Protege 4.3)


Info on WoT presented by Darko at the Lisbon F2F

File:Td-wot-introduction-for-SDWG-TPAC-2016.pptx

Implementation requirements for Rec-Track document

New Implementations are required (YES), or proven, existing implementations are sufficient (NO)
SSN (unchanged, but with new namespace), i.e. http://www.w3.org/ns/ssn/ SSN (changed, i.e. new terms are introduced or old terms are changed) SOSA Core
Rec-Track (normative) NO (if redirect from old terms is in place and equivalence is asserted) YES, for new terms. NO for old terms, that includes DOLCE classes/properties that may be in another namespace, i.e. https://www.w3.org/ns/ssn/dul as long as equivalence and redirects from old namespace are in place. YES, for new terms. NO for old terms if they are imported by SSN and equivalence is asserted. YES for old terms if meaning is redefined, i.e. no equivalence to existing old term can be established.
Rec-Track (non-normative) N/A NO, if new terms are in a non-normative section NO, if SOSA is in non-normative section and uses a different namespace to SSN, e.g. http://www.w3.org/ns/sosa/ or http://www.w3.org/ns/ssn/sosa/
Note N/A NO, if new terms are in a separate namespace and published as a Note, e.g. http://www.w3.org/ns/ssn/actuation/ http://www.w3.org/ns/ssn/observation/ NO, if new terms are in a separate namespace and published as a Note, e.g. http://www.w3.org/ns/sosa/ or http://www.w3.org/ns/ssn/sosa/