- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Tue, 31 Jan 2017 08:28:54 -0800
- To: Kerry Taylor <kerry.taylor@anu.edu.au>, Armin Haller <armin.haller@anu.edu.au>, "Cox, Simon (CESRE, Kensington)" <Simon.Cox@csiro.au>, SDW WG Public List <public-sdw-wg@w3.org>, Scott Simmons <ssimmons@opengeospatial.org>, "fd@w3.org" <fd@w3.org>
- Message-ID: <b44778e2-ca2b-cd1c-10a1-84b82ee1b61e@ucsb.edu>
Hi Kerry,
Okay, Thanks. This needs more discussion. We already have 2 different
namespaces set up by the W3C. You also objected to using imports before
and also to using SOSA concepts directly within the SSN, so I am
confused whether you changed your mind or whether I am misunderstanding
what you are saying. I also discussed with OWL folks about the direct
usage of classes instead of extending them as I believe that will lead
to conflicts and they agreed. Maybe we can discuss this during our telco
today.
Jano
On 01/30/2017 11:07 PM, Kerry Taylor wrote:
>
> Krzysztof ,
>
> I meant by that to separate the issue of namespace from the rest of
> the design. It can work just the same with either 1 or 2 namespaces.
> That cryptic comment was saying that I do not mean my example to be
> interpreted as proposing that there needs to be 2 namespaces. I
> worked the example on the 2 namespace case. If you prefer, you can
> s/sosa:/ssn:/g throughout the example and the design is maintained. I
> copied the “lightweight” axiomitisation of sosa from contemporary
> github – and modified that or the purpose of the example. Same
> treatment for ssn. Re import—I am not sure what you mean but I don’t
> think it matters anyway. (please rephrase and ask again if it really
> does matter). In any case any good architectural/modularity design
> needs to take multiple factors into account and some positive aspects
> may well be traded off against others for a “best” result. I hope you
> can see that in my proposal.
>
> Notwithstanding, some interesting and useful contributions on the
> namespace issue have been put out today by others. Digesting while
> continuing on the day job…
>
> Kerry
>
> *From:*Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
> *Sent:* Tuesday, 31 January 2017 5:32 PM
> *To:* Kerry Taylor <kerry.taylor@anu.edu.au>; Armin Haller
> <armin.haller@anu.edu.au>; Cox, Simon (CESRE, Kensington)
> <Simon.Cox@csiro.au>
> *Subject:* Re: State of SSN
>
> Sorry Kerry, I do not understand what ' In particular I am NOT
> suggesting that sosa:Platform exists at all. On the contrary, it
> should always be ssn:Platform. ' means as all the code below is about
> sosa:Platform. It also does entirely away with the lightweight
> axiomatization we agreed on for SOSA. It also states that SSN imports
> SOSA but you rejected this before. In your example, SOSA also used
> SSN classes but SOSA does not know about SSN, right? What am I
> missing? I am a bit confused.
>
>
> On 01/30/2017 10:22 PM, Kerry Taylor wrote:
>
> Krzysztof ,
>
> Sure – please see the worked example around the Platform class
> Iinked below in this email to which you replied.
> https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017
>
> I am sorry that it took a while to develop the example --- it
> would have made sense to do this much sooner.
>
> -Kerry
>
> *From:*Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
> *Sent:* Tuesday, 31 January 2017 3:30 AM
> *To:* Kerry Taylor <kerry.taylor@anu.edu.au>
> <mailto:kerry.taylor@anu.edu.au>; Rob Atkinson
> <rob@metalinkage.com.au> <mailto:rob@metalinkage.com.au>; 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
>
> Ø) Where SSN needs to create specialisations it can subclass
> as required, in a new namespace - which can resolve to the
> SSN-2 graph
>
> No. And this may be the nub. SSN should only ever extend sosa
> concepts , never subclass. We should standardise the name and
> meaning of a core term (by its rdfs:comment) in the core and
> add deeper axiomatic semantics in extended ssn (acknowledgment
> to Raul for this).
>
>
> Okay, Kerry, so please show us the OWL axiom by which an SSN
> concept 'extends' an SOSA concept without subclassing it? :-)
>
>
> On 01/30/2017 06:35 AM, Kerry Taylor wrote:
>
> Thankyou Rob,
>
> I am really grateful that you summarised one possible
> architecture package. And as far as I can make out it
> accurately reflects one coherent option being proposed
> (although it missed perhaps the rdfs’comments part).
>
> I would like to comment on these 1 by 1 wrt the architecture I
> have proposed over emails and have jst now documented on the wiki.
>
> https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017
>
> Ø1) Regardless of what we call it there will be a new namespace
>
> Not accepted by me and some others. There might be a new
> namespace, but this is highly dependent on architecture as I
> see it.
>
> Ø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)
>
> Agreed (with caveat on “that namespace”)
>
> Ø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)
>
> Agreed (with important caveats about how that richer semantics
> is related to the sosa entities ). Also, unless we have
> strong arguments to the contrary, ssn has existed and been
> widely used for 5+ years (legacy) and we should only change
> what we need to change – ie for which a good argument is made
> and agreed. There is no carte blanche for ssn.
>
> Ø) Where SSN needs to create specialisations it can subclass
> as required, in a new namespace - which can resolve to the
> SSN-2 graph
>
> No. And this may be the nub. SSN should only ever extend sosa
> concepts , never subclass. We should standardise the name and
> meaning of a core term (by its rdfs:comment) in the core and
> add deeper axiomatic semantics in extended ssn (acknowledgment
> to Raul for this).
>
> . 5) informative "Alignments" help others use and understand -
> but dont affect SOSA or SSN semantics - alignments with DUL
> and iso-19150 flavour O&M
>
> The alignment with dul has been removed from ssn as you know,
> but it does affect semantics in that it is implicit in all ssn
> concepts and, if not, requires bigger changes to ssn than I am
> willing to make (remember legacy). So it is “otpional” you
> don’t have to use it but, just as for sosa terms, the
> descriptions of ssn terms (rdfs:comment) should be consistent
> with using the dul alignment.
>
> As for o&M alignment (repeating myself) I believe we need an
> alignment with O&M the OGC standard (which, yes is uml, but
> we can use the “terms” as defined in the standard – and old
> ssn already did that for us anyway!)). I am wary of an
> iso-19150 flavour alignment because it might suggest that we
> think it should or even could be used, and I don’t think we do
> believe that, following the discussion at the last meeting.
> FWIW, I don’t believe that based on personal experience.
>
> > 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.
>
> Phil has advised us to be wary of being driven by the
> implementation demands. However, as the implementation
> requirements and goals to serve our legacy users align well ,
> I believe we should be able to use implelementation evidence
> from the old terms. If we follow the architecture I propose
> then this **could** carry over to sosa terms as well, I think
> – but that is my untested theory and is only happenstance. In
> any case, as you saty we do need the evidence for any new
> concepts.
>
> -Kerry
>
> *From:*Rob Atkinson [mailto:rob@metalinkage.com.au]
> *Sent:* Monday, 30 January 2017 11:59 AM
> *To:* Kerry Taylor <kerry.taylor@anu.edu.au>
> <mailto:kerry.taylor@anu.edu.au>; janowicz@ucsb.edu
> <mailto:janowicz@ucsb.edu>; 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
>
> 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)
> <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 <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 Tuesday, 31 January 2017 16:30:00 UTC