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

On 01/02/2017 20:23, Krzysztof Janowicz wrote:
> Hi,
>
>> 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.
>
> Yes (but see the note below).
>
>> I don't think that SSN-only terms should be defined in the SOSA
>> namespace.
>
> Yes, I could not agree more. SOSA does not "know" about SSN, that is the
> entire point of the lightweight SOSA vocabulary.

+1

>
>> I hope this slight change does not diminish your support Krzysztof.
>
> No, I am still super happy. Can I assume that by "SOSA namespace" and
> "ssn namespace" you imply two namespaces? That would actually make me
> super happy. Most end users use namespaces as handles.

Yes, two namespaces. It is true that you *can* have multiple files with 
multiple URLs all defining terms in the same namespace. IMHO it's just a 
really, really bad idea that will confuse people.

>
>> Proposal 1: That where vocabulary terms are defined in the SOSA
>> namespace, no new term should be defined for SSN.
>
> The tricky part here is how to add more axioms to those concepts that
> are in SOSA, e.g., Sensor, but to which we would like to add further
> axioms in SSN (e.g., that sensors have survival ranges). I will write a
> separate email about this as I know that these decisions may end up
> being more difficult to agree on. My key hope for now is that we can at
> least agree on your proposal without ripping it into pieces and then
> continue with a positive attitude to work out the remaining details. If
> we rip your proposal apart and each of us adds contradicting change
> request we will end up in the same nightmare that we are facing since
> months. So yes, I still fully support your proposal!

I see no problem in defining axioms at /ns/ssn/ that apply to terms 
defined in /ns/sosa/, especially if the SSN ones do, as we have said, 
simply provide tighter semantics, cardinalities etc.



>
> Thanks again Phil!
>
> Jano
>
>
> On 02/01/2017 12:12 PM, Phil Archer wrote:
>> 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:42:07 UTC