- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Sun, 29 Jan 2017 22:28:47 -0800
- To: Rob Atkinson <rob@metalinkage.com.au>, Kerry Taylor <kerry.taylor@anu.edu.au>, Armin Haller <armin.haller@anu.edu.au>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "phila@w3.org" <phila@w3.org>, "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
- Cc: "ssimmons@opengeospatial.org" <ssimmons@opengeospatial.org>, "fd@w3.org" <fd@w3.org>
- Message-ID: <5e560a75-d740-bda0-a5f8-2b127bc16e25@ucsb.edu>
Hi Rob,
> 1) Regardless of what we call it there will be a new namespace
> 2) SOSA contains the broad, inclusive, definitions for things we care
> about - i.e. it will be what lives behind that namespace URL and
> require no specific reasoning on the client side ("lightweight" to use)
> 3) SSN-2 can import and reference these SOSA entities and add
> additonal axioms (in a flavour of OWL with a specific expressivity
> which we should document the intent). (richer semantics but more
> demanding to use)
> 4) Where SSN needs to create specialisations it can subclass as
> required, in a new namespace - which can resolve to the SSN-2 graph
> 5) informative "Alignments" help others use and understand - but dont
> affect SOSA or SSN semantics - alignments with DUL and iso-19150
> flavour O&M
Yes, great summary, this is very much what I believe we wanted to do
since a long time. I think/hope we are all in violent agreement here :-).
> All this is pretty straightforward IMHO until we hit the "legacy SSN" case
Oh yes...
> My naive understanding is if we publish an alignment using strong
> axioms (equivalence or subclass?) then we are able to use original SSN
> deployments as evidence of implementation ... of the subset of
> semantics - but we'd still need IMHO to demonstrate the broader sense
> and any new concepts. So its not trivial and we'd need a plan anyway -
> maybe its easier just to get someone to upgrade their legacy SSN to
> the new SOSA scope and namespace and show the broader definitions are
> usable directly.
>
I think we need new implementation evidence anyway due to the new
namespace. We cannot have equivalence classes between most old SSN and
new SSN classes as the new classes lack DUL and so forth. We also
changed a few other axioms, e.g., on SubSystems. I agree that this is
the part that will need further strategizing and there will be no
perfect solution.
Cheers,
Jano
On 01/29/2017 04:59 PM, Rob Atkinson wrote:
>
> I think Kerry is correct to say we need to get on the same page with
> the "architecture" - and until we do that its hard to actually
> understand everybody's positions. Perhaps we focus on what that
> architecture means for users and the process?
>
> Here's my understanding of that architecture:
>
> 1) Regardless of what we call it there will be a new namespace
> 2) SOSA contains the broad, inclusive, definitions for things we care
> about - i.e. it will be what lives behind that namespace URL and
> require no specific reasoning on the client side ("lightweight" to use)
> 3) SSN-2 can import and reference these SOSA entities and add
> additonal axioms (in a flavour of OWL with a specific expressivity
> which we should document the intent). (richer semantics but more
> demanding to use)
> 4) Where SSN needs to create specialisations it can subclass as
> required, in a new namespace - which can resolve to the SSN-2 graph
> 5) informative "Alignments" help others use and understand - but dont
> affect SOSA or SSN semantics - alignments with DUL and iso-19150
> flavour O&M
>
> All this is pretty straightforward IMHO until we hit the "legacy SSN" case
>
> My naive understanding is if we publish an alignment using strong
> axioms (equivalence or subclass?) then we are able to use original SSN
> deployments as evidence of implementation ... of the subset of
> semantics - but we'd still need IMHO to demonstrate the broader sense
> and any new concepts. So its not trivial and we'd need a plan anyway -
> maybe its easier just to get someone to upgrade their legacy SSN to
> the new SOSA scope and namespace and show the broader definitions are
> usable directly.
>
> Rob
>
>
>
> On Mon, 30 Jan 2017 at 10:53 Kerry Taylor <kerry.taylor@anu.edu.au
> <mailto:kerry.taylor@anu.edu.au>> wrote:
>
> _>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
> <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;
> 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 <tel:+44%207887%20767755>
>
> @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 06:29:25 UTC