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

Very pleased to see this clarification and convergence. 
I would like to support Phil and Jano's proposal. 

Yes there will be some details to work out, but the general principle is clear: in order to satisfy both rigour and community expectations, we will need (at least) two files, ontologies, and namespaces. Everything else is tractable detail within that framework. So my vote is 

1. + 2a. 

---
On SOSA-SSN equivalences, see the commentary with this pull-request - 
https://github.com/w3c/sdw/pull/517 and also the mail sent to the list https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0207.html

I had come to essentially the same conclusion as Phil. 

---
There are already several resources available related to the O&M alignment,

A. I dropped this into GitHub a while back
https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/om.ttl 
It was an attempt to re-imagine om-lite as a SOSA application. 
There was no claim to consensus, or that this should be part of the spec. It was primarily an exercise to test the modular architecture proposal. There may be some minor tweaks required now (and I think I may have used namespaces also used below), but practically it provides evidence in support. This has been on the table since July 2016. 

B. And over the weekend, in response to ACTION-255 I crafted two separate alignment graphs
1. https://github.com/w3c/sdw/blob/simon-ssn-O%26M-alignments/ssn/rdf/sosa-om-mapping.ttl which maps from SOSA to O&M using the official ISO 19150-2 URIs to identify the classes and properties from the UML model 
 - OGC works closely with ISO, and OGC O&M is also published as ISO 19156, so **this could be normative**
2. https://github.com/w3c/sdw/blob/simon-ssn-O%26M-alignments/ssn/rdf/sosa-oml-mapping.ttl which maps from SOSA to om-lite/sam-lite
 - as Phil points out, om-lite does not have any official organizational endorsement (it is from a paper in Semantic Web Journal). So if it stays in the spec at all, perhaps in an informative annex? 

I already drafted a chapter for the spec describing both of these - see Chapter 8 in https://github.com/w3c/sdw/blob/simon-ssn-O%26M-alignments/ssn/index.html 


-----Original Message-----
From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu] 
Sent: Thursday, 2 February, 2017 07:23
To: Phil Archer <phila@w3.org>; SDW WG Public List <public-sdw-wg@w3.org>; ssimmons@opengeospatial.org; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; Armin Haller <armin.haller@anu.edu.au>
Subject: Re: Proposals (was Re: Architecture of SOSA/SSN integration)

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.

> 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.

> 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!

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#Co

>>>> mpromise_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
>>>>
>>>
>>
>>
>


--
Krzysztof Janowicz

Geography Department, University of California, Santa Barbara
4830 Ellison Hall, Santa Barbara, CA 93106-4060

Email: jano@geog.ucsb.edu
Webpage: http://geog.ucsb.edu/~jano/

Semantic Web Journal: http://www.semantic-web-journal.net

Received on Wednesday, 1 February 2017 22:21:07 UTC