- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Mon, 30 Jan 2017 08:12:13 -0800
- To: Kerry Taylor <kerry.taylor@anu.edu.au>, Rob Atkinson <rob@metalinkage.com.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: <e52236ee-6356-0688-306a-d5cf6c7815e8@ucsb.edu>
> Personally – I am unconvinced that multiple namespace have any
> purpose. Therefore , if there is no purpose, one namespace should be used.
We have two namespace:
See: http://w3c.github.io/sdw/ssn/
"The namespace for SSN terms is http://www.w3.org/ns/ssn/
The suggested prefix for the SSN namespace is ssn
The SSN ontology itself is available at http://www.w3.org/ns/ssn/"
"The namespace for SOSA terms is http://www.w3.org/ns/sosa/
The suggested prefix for the SOSA namespace is sosa
The SOSA ontology itself is available at: http://www.w3.org/ns/sosa/."
> ØWe also changed a few other axioms, e.g., on SubSystems.
>
> I missed that entirely. When? Where?
You missed your own change???
See https://www.w3.org/2015/spatial/track/issues/85
We even had a vote that lets you do whatever you like just to let us
move on; see https://www.w3.org/2016/11/29-sdwssn-minutes : "<ahaller2>
kerry to decide on issue 85 as editor of the new SSN". So, I assume you
change the hasSubSystem axiom, right?
Jano
On 01/29/2017 11:07 PM, Kerry Taylor wrote:
>
> Actually there have been several emails on the list that disagree
> with this statement (as presented in earlier times) And a
> presentation at an SSN meeting on this topic too.
>
> Ø1) Regardless of what we call it there will be a new namespace
>
> Those opinions have been ignored and deserve listening to.
>
> The “legacy SSN" case” is not an issue provided the core is designed
> appropriately. If there eis an “issue” it purely arises from the
> current core being designed independently of the ssn of which it is
> the core. Fixing this requires adjustment to both legacy ssn and the
> current version of the core.
>
> Personally – I am unconvinced that multiple namespace have any
> purpose. Therefore , if there is no purpose, one namespace should be used.
>
> > ) Where SSN needs to create specialisations it can subclass as
> required, in a new namespace - which can resolve to the SSN-2 graph
>
> I am in violent disagreement with this statement., as I have said many
> times previously. Sorry to bore the list.
>
> ØWe also changed a few other axioms, e.g., on SubSystems.
>
> I missed that entirely. When? Where?
>
> --Kerry
>
> *From:*Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
> *Sent:* Monday, 30 January 2017 5:29 PM
> *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; phila@w3.org; public-sdw-wg@w3.org
> *Cc:* ssimmons@opengeospatial.org; fd@w3.org
> *Subject:* Re: State of SSN
>
> 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
> <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) 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://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 <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 16:12:53 UTC