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

Thanks for pointing out that there is more to SSN than what's in the 
mapping table, I should have checked that.

OK, so then I do think the SSN-only terms should be in the ssn 
namespace, but where a term exists in SOSA, that's the one we use. I 
don't think that SSN-only terms should be defined in the SOSA namespace. 
Therefore, my proposals become:

Proposal 1: That where vocabulary terms are defined in the SOSA 
namespace, no new term should be defined for SSN.

Then:

Proposal 2A: That SSN is characterised as a semantic layer on top of 
SOSA, with additional terms.

OR

Proposal 2B: That SSN is characterised as a profile of SOSA.

I hope this slight change does not diminish your support Krzysztof.

Phil



On 01/02/2017 18:33, Krzysztof Janowicz wrote:
> Dear Phil, all,
>
> Thanks a lot for your thoughts and providing this overview. I would like
> to express my *strongest* possible support for your proposal and hope we
> can finally move forward and understand that no single solution will
> make everybody perfectly happy. What you are proposing is largely in
> line with what many of us have been suggesting and working on for
> months. Please find detailed comments in line.
>
>> 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.
>
> Yes, exactly. But please let me add a few more important detail here.
> SOSA is not only lightweight it also targets a different audience,
> namely those that would typically be attracted to schema.org-style
> semantic annotations. Hence, SSN can/should "use" (e.g., import
> subclass, load, profile, etc. [use whatever term makes you happy here])
> SOSA but not the other way around. Consequently, SOSA has to be designed
> in a way that it can be used entirely independently of SSN. On the other
> hand, SSN really has to use SOSA in some way and here is why: As we
> discussed before, SOSA also acts as a interoperability fallback level.
> What we do *not* want is that SOSA and SSN users cannot exchange data.
> However, and following the current design principles of SOSA, SOSA also
> acts as common core of both, and, thus SSN users and SOSA users can
> indeed exchange data although they do so on a more abstract level. If
> you like object-oriented design/programming, then this idea should sound
> familiar as it is underlying interfaces, generics, inheritance, and so
> forth, and it has been immensely successful.
>
>> It defines a class of Actuation that does not appear in SSN or the
>> others. Nothing more to say.
>
> Yes, and this is not a problem. Same for Sample. We simply forgot about
> this in the old-SSN.
>
>>
>> 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.
>
> Yes, exactly. This is where many of us hope to go and this is what has
> been proposed over and over again. Btw, Observation is really the only
> critical part here as O&M and old-SSN had a clear difference here. This
> is not dramatic, just something that we need to work on. I have some
> ideas for this that would also solve our current hasValue problem (I
> wrote an email about this some days ago and will report back on results
> asap with the hope to receive feedback).
>
>> But again, it's the SOSA namespace that wins. If we need to tweak the
>> SOSA definitions, do it.
>
> Yes!
>
>>
>> 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.
>
> Yes! And keeping in mind that SOSA is more general by design. This also
> explains why from a set-theoretic perspective SOSA categories (due to
> the lightweight semantics of SOSA classes) are more inclusive than SSN
> categories and, in fact, contain them. Please also note that due to the
> fact that SOSA has a more lightweight semantics, we need more detailed
> human readable class descriptions and this is why we have a bit more
> text and examples then we had in the old-SSN. In the old-SSN we also
> made some mistakes that we can clean up, nobody is perfect after all.
>
>>
>> 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.
>
> We need to change how we handle values as this part got lost when we
> removed the direct linkage to DUL. I am working on this based on the new
> version of the QUDT ontology (http://qudt.org/). This will make sure we
> are compatible with a very important and widely used ontology. I will
> report back on my results as soon as we have agreed on your proposal.
> Otherwise I will have to change everything over and over again.
>
>> What's the difference between sosa:hosts and sosa:attachedSystem ? Do
>> we need both?
>
> SOSA should not have an attachedSystem relation. Do you mean SSN?
>
>>
>> Hang on, that's *it*. There is no more.
>
> Agreed. This is why we have always tried to highlight that although we
> have different opinions and different proposals, they differ by rather
> small pieces. Almost all of us agree that we can adjust/align/integrate
> SOSA and SSN without major efforts.
>
>>
>> Question: do we really need ssn:SensorOutput and ssn:ObservationValue
>> or could we live with just sosa:Result?
>
> See above. This problem will go away on its own.
>
>> Based on the mapping table, I end up with just *two* classes and *no*
>> properties in the SSN namespace.
>
> There is more to SSN, namely survival ranges of sensors and so forth.
>
>> So we're talking here about SSN essentially adding further semantic
>> constraints on SOSA, not new terms (except possibly two new classes).
>
> SSN contains more, see above. Deployment is another example. This is not
> a problem as these classes and relations do not appear in SOSA. SOSA is
> simply not the place where one would go into all the details on how a
> sensor is constructed and so on, but SSN allows us to do so.
>
>> 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.
>
> I am fine with calling it a vocabulary but as it has OWL axioms I would
> prefer to call it ontology. Again, I am fine with whatever the majority
> wants. Maybe 'vocabulary' is even better for our envisioned end users.
>
>> 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.
>
> This is where I would personally disagree as SSN adds substantially more
> content (see above) and end users tend to confuse namespaces and use
> them for communication. Also note that SSN is a bit of an odd name as we
> ended up not really talking a lot about (N)etworks. That said, and while
> I would strongly prefer two namespaces for clarity, if we all agree to
> go with your suggestion, I will certainly not risk a discussion on
> namespaces if everybody else would prefer just one namespace.
>
>> 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.
>
> Yes and we have Simon Cox on the team so this should really not be a
> difficult issue. I hope we can give Simon a more active role here but
> this is a separate discussion. O&M is really important if we want
> SOSA/new-SSN to be a success story.
>
>> What about om-lite and sam-lite?
>
> IMHO, om-lite is a subset of O&M and is already compatible with SOSA. In
> fact, Simon posted an alignment between SOSA and om-lite in summer of
> 2016 on our github.
>
>>
>> 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.
>
> This is a problematic point especially with respect to old-SSN and
> new-SSN. I can demonstrate why this is problematic in a separate email
> but I would strongly suggest we have the DUL alignment as an optional
> part. Which should not be confused with me saying that it does not
> matter. Also note that the idea of contextualized/scoped/optional axioms
> does not exist in W3C OWL.
>
>>
>> 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.
>
> I would vote for 1 but this is probably a more difficult discussion.
>
> Dear SSN members, please let us accept Phil's proposal without getting
> into little infights, very particular details, changes, endless change
> request, and so forth as we did over the past 6+ months. No proposal
> will ever make everybody absolutely happy but Phil's proposal comes from
> a neutral stance and captures almost all aspects we discussed so many
> times and that many of us supported by their votes over and over and
> over again. More details remain to be clarified, but let us do this
> after we agreed on this general outline.
>
> Jano
>
>
> On 02/01/2017 08:40 AM, Phil Archer 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 20:12:11 UTC