Warning:
This wiki has been archived and is now read-only.
SSN Tasks
From Spatial Data on the Web Working Group
- Check and reconsider/redesign modularisation of SSN into patterns
- Clearly separate observation, sensor, and deployment parts.
- Disentangle SSN from DUL (this may require adding things to SSN that are needed from DUL)
- Reconsider O&M alignment (see O&Mlite) - as alternative to DUL?
- Provide deeper OWL axiomatization (now that DUL is gone) - kjanowicz to explain
- See proposal in charter: noting the work to split the ontology into smaller sections to offer simplified access.
- Align with Prov-o
- Discuss potential need of rdf datacube alignment (pre-Coverage work)
- Extend to cover UCRs and/or wish list items
- What goes in SSN and what should be a recommended profile/extract/extension (use kjanowicz's analysis of literature)?
- Develop targeted versions/profiles/extracts/extensions (e.g. Wot? Iot-lite? satelite sensors? samples? human sensors? advise how to do this?
- Re-consider actuation with WoT
- Sampling features - specimens and sites - as described in several of the submitted use-cases, esp Marine Observations
- Revisit annotation properties, including multilingual
- Transfer/link/align common issues with BP and UCR deliverables.
- Write the specs (in what form?)
- 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).
Contents
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
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]
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
- Because a sensor was always meant to include computational methods -- see the English annotation description
- Because some people think that a "physical object" cannot include a computational method (others disagree)
- 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.
- 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).
- 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/ |