- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Sun, 29 Jan 2017 18:55:03 -0800
- To: Simon.Cox@csiro.au, kerry.taylor@anu.edu.au, armin.haller@anu.edu.au, phila@w3.org, public-sdw-wg@w3.org
- Cc: ssimmons@opengeospatial.org, fd@w3.org
- Message-ID: <d099d48b-2e62-48b6-e5a6-66c8e78c4afa@ucsb.edu>
> 1.from last week’s email my impression was that a consensus was > emerging that ssn would import sosa and then either add axioms to the > sosa classes, or sub-class them. That isn’t alignment, its just > ontology engineering. Yes, and just as a reminder, this has been part of our draft, wikipages, figures, and discussions for like 8-9 months now. On 01/29/2017 06:14 PM, Simon.Cox@csiro.au wrote: > > ØAnd, for the record, I do not accept that that any alignment between > ssn or sosa is either useful or necessary. It is frankly absurd that > an ontology needs to be ”aligned” with it’s own core! > > Thanks Kerry – > > I agree – ‘alignment’ of ssn and sosa is missing the point. I was > under the impression that, if sosa is the core, then ssn would build > on it by adding formal axioms to sosa (which is axiomatically very > weak, by design). > > Now there are a couple of ways to do this. > > 1.from last week’s email my impression was that a consensus was > emerging that ssn would import sosa and then either add axioms to the > sosa classes, or sub-class them. That isn’t alignment, its just > ontology engineering. > > 2.OTOH – if classes that have been defined in SOSA have exact > equivalents in SSN, and these are not replaced by the SOSA classes, > then we are in alignment territory. As you say, that is really > unnecessary. > > I pushed some thoughts along the lines of option 1. into the GitHub > this morning and requested a review. > > See https://github.com/w3c/sdw/pull/517 > <https://github.com/w3c/sdw/pull/517> > > The specific places where a ssn class could be replaced by sosa > classes have merely been annotated with skos:editorialNote so far. > > However, in a few places where sub-classing appeared to be required, I > did add those axioms. > > Simon > > *From:*Kerry Taylor [mailto:kerry.taylor@anu.edu.au] > *Sent:* Monday, 30 January, 2017 10:53 > *To:* janowicz@ucsb.edu; Armin Haller <armin.haller@anu.edu.au>; Cox, > Simon (L&W, Clayton) <Simon.Cox@csiro.au>; phila@w3.org; > public-sdw-wg@w3.org > *Cc:* ssimmons@opengeospatial.org; fd@w3.org > *Subject:* RE: State of SSN > > _>Option 2: SSN new imports SOSA *and* “extends” classes/properties > from SOSA: _In this option both ontologies use a separate namespace, > but /SSN new/ extends >SOSA, meaning /SSN new/ uses the SOSA namespace > for concepts/properties that are shared between SOSA and /SSN new/ and > “extends” (narrows) them with >stronger OWL axiomatizations. > > This is close, but not an accurate representation of my position. > Please see the multiply-posted comments under the topic of issue-88 , > including but by no means limited to : > https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0099.html > > I will endeavour to write it up again on the wiki --- with a worked > example if I can for the next ssn meeting, although I cannot promise > to complete in time. > > I would like to add that I don’t see how these things can be solved > term by term or comment-by-comment as is currently proposed by the > Chair. The architecture of modularisation has been questioned for a > **very** long time (and there are multiple unresolved issues on the > tracker on this topic e.g. issue-37, issue-115, issue-120, issue-139) > yet has failed to be fully articulated ---- so it seems we all have, > unsurprisingly, different interpretations of the intention. The fact > that sosa , as the “core” module of ssn, was developed quite > independently of ssn and with apparent disregard of these > modularisation/architecture questions is rather unfortunate --- but > nothing that can not be fixed. > > And, for the record, I do not accept that that any alignment between > ssn or sosa is either useful or necessary. It is frankly absurd that > an ontology needs to be ”aligned” with it’s own core! The alignment > proposed in the past week is also highly faulty – I need to put this > opinion on the record only because I am wary of being told again > that “we all agreed” with something that has simply been posted to > github by surprise. However, because I believe it is neither useful > nor necessary I will not go into details of the faults here. > > --Kerry > > *From:*Krzysztof Janowicz [mailto:janowicz@ucsb.edu] > *Sent:* Thursday, 26 January 2017 2:09 PM > *To:* Armin Haller <armin.haller@anu.edu.au > <mailto:armin.haller@anu.edu.au>>; Simon.Cox@csiro.au > <mailto:Simon.Cox@csiro.au>; phila@w3.org <mailto:phila@w3.org>; > public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org> > *Cc:* ssimmons@opengeospatial.org > <mailto:ssimmons@opengeospatial.org>; fd@w3.org <mailto:fd@w3.org> > *Subject:* Re: State of SSN > > Hi All, > > Thanks Armin for the nice summary! > > Please note however that option 3 would contradict our own figures and > draft as pointed out by Phil and this figure (and text) has been > around for a year now. > > Options 1 and 2 are what we need and as SSN imports SOSA anyway, 2 may > be easier solution. > > Wrt to the comments, I agree with the idea in general (and proposed it > myself before) but think we need to be very, very careful here. > *Abstract* comments are almost never a good idea and may actually hurt > SOSA *and* SSN. Again, just to be clear about this, ideally we would > have the same comment but this comment has to be on a level that is > directly understandable and usable, i.e., not too abstract. > > Frankly speaking, I am not so happy with having them reworked all at a > time by a single person and then presented. Why don't we use the next > 2-3 telco's to do this together class by class as a group so that we > do not have to re-discuss them afterwards over and over again to find > a compromise. We are really running late by now :-) > > Cheers and thanks again! > Jano > > P.s. Let us also please switch back to a mode where everybody > participates regularly and does not merely jump in a few times per > year to revisit decisions taken months ago, and let us also all work > in a constructive and supportive atmosphere. We have a great and > impactful product and we are all interested in getting it in the best > possible shape. > > > > On 01/25/2017 03:36 PM, Armin Haller wrote: > > Hi Phil, > > Thanks for raising these points. I had a longer F2F conversation > with Kerry yesterday to discuss her concerns around the SOSA/SSN > alignment and the more general issue she raised with > https://www.w3.org/2015/spatial/track/issues/139. I think I now > understand her preference, which I will outline in this email. > Before, I want to more clearly outline the options we have in > terms of alignment between SOSA and /SSN new /as of Point 6 from > Phil below, seeing SOSA as the core as already outlined in the > first working draft. > > _Option 1: SSN new imports SOSA *and* > equivalence/subclass/subproperty relations are defined in SSN_: In > this option both ontologies use a separate namespace and /SSN ne/w > introduces its own classes/properties (in its own namespace) even > for concepts/properties that are common to both ontologies, while > doing so asserting equivalence and subclass/subproperty relations > for those classes that are common and where appropriate. > > _Option 2: SSN new imports SOSA *and* “extends” classes/properties > from SOSA: _In this option both ontologies use a separate > namespace, but /SSN new/ extends SOSA, meaning /SSN new/ uses the > SOSA namespace for concepts/properties that are shared between > SOSA and /SSN new/ and “extends” (narrows) them with stronger OWL > axiomatizations. > > _Option 3: SSN does not import SOSA *and* alignment between SOSA > and SSN is defined in a separate file/namespace:_ This approach is > similar to how we align /SSN new/ to DULCE, i.e. the alignment is > in a separate file with its separate namespace. > > Although my personal preference from the beginning was on Option > 2, my belief was that some group members are against this option, > in particular, Kerry, and I was under the working assumption that > at best we will achieve Option 3. In my discussion with Kerry > yesterday she made it very clear that she prefers _direct usage of > SOSA classes/properties in SSN new_. This includes the > introduction of properties in /SSN new/ that are defined in SOSA > for simplicity (traversing a property path of SSN new) while > adding axioms to ensure the equivalence of these simplified > properties to a property path. This also means that rdfs:comments > will be shared between SOSA and /SSN new/. Since neither of the > rdfs:comments in our mapping table on the wiki > (https://www.w3.org/2015/spatial/wiki/Mapping_Table) > <https://www.w3.org/2015/spatial/wiki/Mapping_Table%29> are yet > particularly suited for this purpose, the proposal was: > > -To create one very abstract description for each shared concept > that _DOES NOT_ refer to classes/properties (i.e. using capital > letters or camel casing), but uses English natural language. This > rdfs:comment can then be _supplemented by annotation properties_ > in the two respective namespaces of SOSA and SSN new. These > annotation properties can add examples, refer to classes and > properties in the respective namespace using capital letters and > describe the stronger semantics as required by /SSN new/. > > *If there is no objection from the group, I have volunteered to > start with such an abstract description for the rdfs:comments in > the mapping table. *I cannot guarantee to finish by our meeting > next week, but I will attempt to at least finish some of those. > > Beyond that, the agreement with Kerry was that we continue (in the > phone calls) with addressing the issues that have been already > identified (by her) in the issue tracker in the alignment between > SOSA and /SSN new/. > > Kind regards, > > Armin > > On 25/1/17, 11:28 pm, "Simon.Cox@csiro.au" > <mailto:Simon.Cox@csiro.au> <Simon.Cox@csiro.au> > <mailto:Simon.Cox@csiro.au> wrote: > > Thanks Phil - > > Just want to comment on your item 2. > > SOSA is not 'inspired by O&M' any more than it is by any of > the other prior work. It was an attempt to define a core with > lightweight semantics for an audience interested in describing > observations, actuation or sampling. The hope was that it could > also serve as a core for more semantically rich vocabularies, > along the lines proposed by Jano (aka vertical and horizontal > modularization). So the scope of SOSA is broad but it is > axiomatically shallow - deliberately not much more than schema-org > style. Certainly it picks up some ideas from O&M, in particular > the notion of Samples, but it also picks up ideas from IoT > (Actuators) and SSN (Platform, properties of Sensors). SOSA is > definitely not something that has just come from the O&M camp. > > Simon > > -----Original Message----- > > From: Phil Archer [mailto:phila@w3.org] > > Sent: Wednesday, 25 January, 2017 20:41 > > To: SDW WG Public List <public-sdw-wg@w3.org> > <mailto:public-sdw-wg@w3.org> > > Cc: Scott Simmons <ssimmons@opengeospatial.org> > <mailto:ssimmons@opengeospatial.org>; Francois Daoust <fd@w3.org> > <mailto:fd@w3.org> > > Subject: State of SSN > > Dear all, > > As team contact for the WG, my role is not necessarily to get > involved in every aspect of each of our deliverables. As is > abundantly clear from our discussions over the last couple of > years, the WG members are the domain experts, not me. But, all is > not well in the state of SSN and so I feel that I need to take a > more active position. My mail on Monday [1] is part of that. > > My understanding of the current situation is likely to be less > than 100% accurate - I know that - but what I see is: > > 1. There is a lot of prior work that predates the WG: SSN, > O&M, Dolce. > > 2. There is SOSA, which is, I think I'm right in saying, > largely inspired by the work to represent O&M in OWL and create a > simple version for wider use. > > 3. There is a very understandable desire to see this work > become a formal standard - that's what we're chartered to do. This > entails gathering evidence of usage. But the problem is that the > evidence that exists is from earlier work. What's being done now > might be too new and we may not be able to gather that > implementation evidence. That would be a pity but it's better than > a bad design driven by process. SSN has a reputation for being too > complicated so let's not hesitate to simplify it. > > 4. The published document states clearly that SOSA is the core > and that SSN is an outer ring, with O&M and Dolce Ultra Lite > alignments outside both. > > 5. There is a debate about whether the alignments, especially > with O&M, should be normative. In favour: O&M is a formal standard > and it feels right to me that it should be but I'm open to > persuasion either way. > > 6. There is a debate about whether the SOSA-SSN relationship > should be couched as sub classes/properties or whether one should > be an extension of the other. That's a legitimate technical > argument. Over to you to sort it - but as a design principle, > please don't have the same property/class names in the two > namespaces with different semantics (ssn:Platform and > sosa:Platform, for example). My instinct is to prefer direct usage > over sub classes but that's a generalist's view. > > 7. There is work going on concerning the SOSA-SSN alignment > that is being shared piecemeal, issue by issue. That is not right. > Put it on the wiki or GH, argue about it, edit it in front of > everyone. The idea of "we'll share it when it's finished" is not > the way we should work. > > 8. There is a lot of unhappiness in the SSN group at the > moment, which is unfortunate and needs to be fixed before everyone > walks away. > > 9. If the group so wishes, we can easily arrange a one off > long telco. > > Phil. > > [1] > https://lists.w3.org/Archives/Public/public-sdw-wg/2017Jan/0096.html > > -- > > Phil Archer > > Data Strategist, W3C > > http://www.w3.org/ > > http://philarcher.org > > +44 (0)7887 767755 > > @philarcher1 > > -- > Krzysztof Janowicz > Geography Department, University of California, Santa Barbara > 4830 Ellison Hall, Santa Barbara, CA 93106-4060 > Email:jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu> > Webpage:http://geog.ucsb.edu/~jano/ <http://geog.ucsb.edu/%7Ejano/> > Semantic Web Journal:http://www.semantic-web-journal.net -- 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 Monday, 30 January 2017 02:55:47 UTC