- From: Phil Archer <phila@w3.org>
- Date: Wed, 1 Feb 2017 21:09:45 +0000
- To: SDW WG Public List <public-sdw-wg@w3.org>
I think this was meant for the list -------- Forwarded Message -------- Subject: Re: Proposals (was Re: Architecture of SOSA/SSN integration) Date: Wed, 1 Feb 2017 12:47:47 -0800 From: Krzysztof Janowicz <janowicz@ucsb.edu> Reply-To: janowicz@ucsb.edu To: Phil Archer <phila@w3.org> > 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. Yes to 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. Yes! > > 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. This depends on whether we have two URLs, namespaces, and so on. This is why I hope we can agree on your proposal namely on two files, two URLs, and two namespaces. Btw, this is also what we tried to get a vote on yesterday. Best, Jano On 02/01/2017 12:42 PM, Phil Archer wrote: > > > 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 >>>>>> >>>>> >>>> >>>> >>> >> >> > -- 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 21:09:28 UTC