Re: Proposals (was Re: Architecture of SOSA/SSN integration)

Phil,

Thanks for the “clean scrape” of the topic. Your logic makes a lot of sense and now maybe I can go back through the huge number of email threads and make better sense of what has been discussed!

Best Regards,
Scott

> On Feb 1, 2017, at 9:40 AM, Phil Archer <phila@w3.org> wrote:
> 
> Dear all,
> 
> I am sorry that I was only able to take part in the first half of the meeting yesterday.
> 
> I've been looking at the mapping table [1] and trying to make some more sense of what I see and offer how I personally would choose to proceed. In doing this I admit that I have been too lax, allowing the task force to continue its work without taking the time to understand the detail of what was being discussed. This is unhelpful and I bear some responsibility at least for the current malaise. I offer what follows as a possible way forward. In doing so, please be sure that I do not have any special powers. This is not a diktat from W3C, just a proposal from a WG member.
> 
> I believe the currently published document expresses the consensus view that SOSA is the semantically light weight core and that SSN is the semantically richer and more specific ontology.
> 
> OK, so we start with SOSA.
> 
> It defines a class of Actuation that does not appear in SSN or the others. Nothing more to say.
> 
> Both SOSA and SSN have an Observation class. In my view, ssn:Observation should be deleted and SSN users should use sosa:Observation. Ditto for all classes where any differences can be ironed out.
> 
> But again, it's the SOSA namespace that wins. If we need to tweak the SOSA definitions, do it.
> 
> Then we get to sosa:ObservableProperty and ssn:Property.
> 
> Looking at the two definitions, there are differences but they look very minor to my eyes with sosa:ObservableProperty looking slightly more general, so, again, I'd delete ssn:Property.
> 
> Only when we get to sosa:Result do we see something different, i.e. ssn:SensorOutput and ssn:ObservationValue. OK, so here, for me, are the only classes in the ssn namespace, both of which are subclasses of sosa:Result.
> 
> On to properties.
> 
> Using the same logic, I would delete:
> 
> ssn:featureOfInterest
> ssn:observationResult
> ssn:observes
> ssn:observedProperty
> ssn:sensingMethodUsed
> ssn:madeObservation (and move ssn:observedBy to the sosa namespace to be consistent with the other inverse properties)
> ssn:onPlatform
> ssn:observationSamplingTime
> ssn:observationResultTime
> 
> What's the difference between sosa:hosts and sosa:attachedSystem ? Do we need both?
> 
> Hang on, that's *it*. There is no more.
> 
> Based on the mapping table, I end up with just *two* classes and *no* properties in the SSN namespace.
> 
> Question: do we really need ssn:SensorOutput and ssn:ObservationValue or could we live with just sosa:Result?
> 
> So we're talking here about SSN essentially adding further semantic constraints on SOSA, not new terms (except possibly two new classes).
> 
> That's what I call a profile, i.e. a way in which a particular vocabulary is used, complete with cardinality constraints and more finely tuned semantics. We can add textual usage notes and descriptions as well as semantic axioms but I see no new terms to add.
> 
> So here's my table of contents for the document:
> 
> 1. Introduction
> 2. Developments since the initial 2009 publication of SSN
> 3. Modularization
> 4. The SOSA ontology
> 5. The SSN Semantic Layer
> The SOSA vocabulary (it doesn't have rich enough semantics to be called an ontology in my view) is deliberately defined with loose semantics - just enough for everyday applications.
> 
> Where more precise semantics are needed, such as in @@@use case@@@ and @@@ use case@@@ an additional layer can be applied. This allows data encoded using SOSA to be processed using an OWL resoner.
> 
> Then define all the semantics you like in a file at /ns/ssn/.
> 
> We've been arguing about the namespace for the SSN terms. Kerry has been saying that we don't need another namespace. Reading through the mapping table, now I see why: personally, I only see one vocabulary.
> 
> 6. Alignment to OGC Observations and Measurements
> 
> Looks like a pretty straightforward alignment to me. I presume consideration was given to using O&M terms directly in SOSA? Can they not be used directly? If not, it looks to me as if SOSA terms could be declared as sub classes and properties of O&M terms.
> 
> I'd say that this can be part of the normative definition of SOSA.
> 
> What about om-lite and sam-lite?
> 
> Well, they look pretty similar too. Am I right that these are CSIRO-only ontologies? In which case, I'd say that any alignment is up to CSIRO to do and publish.
> 
> 7. Alignment to SSN of the SSN-XG, ssn-ssnx.
> 
> I'd include those assertions in a sub chapter of the one on SSN.
> 
> 8. Alignment to DOLCE+DNS Ultralite upper ontology (DUL)
> 
> For me this is optional but if there's no harm in including it, go ahead.
> 
> I am feeling very guilty. I should have looked at that mapping table before now. I think I have learned a lesson.
> 
> Proposal 1: That all vocabulary terms are defined in the SOSA namespace.
> 
> Proposal 2A: That SSN is characterised as a semantic layer on top of SOSA.
> 
> OR
> 
> Proposal 2B: That SSN is characterised as a profile of SOSA.
> 
> Personally, I'd vote in favour of 1 and 2B.
> 
> Phil
> 
> 
> [1] https://www.w3.org/2015/spatial/wiki/Mapping_Table
> 
> On 31/01/2017 23:39, Armin Haller wrote:
>> Hi,
>> 
>> Herewith I am trying to summarise what has been discussed in today’s meeting, what was discussed and proposed on the list and what we have already decided on earlier in the working group:
>> 
>> 
>> ·         SOSA and SSN use Slash URIs/IRIs
>> 
>> ·         SOSA and SSN use different IRIs and are serialised in separate ontology files (everyone expect Kerry agreed on that one, although there is her proposal on the wiki stating the same: https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017)
>> 
>> ·         SOSA and SSN may use different ontology namespaces
>> 
>> ·         SOSA uses simple semantics as decided upon earlier (i.e. owl classes, datatype and object properties, inverse properties, but no domain/range and no other owl restrictions)
>> 
>> ·         SSN imports SOSA
>> 
>> ·         SSN introduces stronger semantics, using several types of OWL restrictions. As far as I can tell, four options have been presented to add these additional semantics through the import of SOSA:
>> 
>> 1.       SSN introduces new classes/properties in its ontology namespace and introduces where appropriate equivalence relations to the class/property in SOSA
>> 
>> 2.       SSN introduces new classes/properties in its ontology namespace and introduces subclass relations and where appropriate equivalence relations to the class/property in SOSA
>> 
>> 3.       SSN reuses the IRI for classes/properties defined in SOSA and introduces further axioms that “narrow” their meaning, but does not introduce subclass or equivalence relations relying on the user to choose through the ontology namespace the interpretation of the ontology.
>> 
>> 4.       A separate core essentially introduces vocabulary terms with no semantics, only a description and a label (very abstract, similar to the annotations that I have added to the wiki https://www.w3.org/2015/spatial/wiki/Mapping_Table and we had no time to discuss), but its own IRI and “ontology” namespace. Both SOSA and SSN import this vocabulary and extend it with different semantics, solving the issue that SSN has two different IRIs for some classes/properties as would be the case in Option 1-2.
>> 
>> I had the impression that there was no strong objection against any of these options in the call today, but several issues have been raised.
>> 
>> ·         In option 3 the issue that has been raised was that users who use a class/property in their tool of choice may not know which semantic interpretation should be used in the given context.
>> 
>> ·         Earlier on the mailing list, an issues has arising that in Option 3 SSN would use the SOSA IRIs for several classes/properties whereas the old SSN only had one IRI for those classes/properties. That could potentially be solved with Option 4.
>> 
>> Please let me know if I missed an option.
>> 
>> Cheers,
>> Armin
>> 
> 
> -- 
> 
> 
> Phil Archer
> Data Strategist, W3C
> http://www.w3.org/
> 
> http://philarcher.org
> +44 (0)7887 767755
> @philarcher1
>

Received on Wednesday, 1 February 2017 17:05:50 UTC