RE: Architecture of SOSA/SSN integration

Rob,

Ø  is it meaningful to "add axioms to a namespace"? I thought you would add them to an ontology, which can reuse the original namespaces.



No, it is not meaningful to add axioms to a namespace. And yes,  you can add axioms to any ontology which reuses any namespaces you like.  However *if* you assume that an ontology must reside at a namespace url for some terms (presumably terms that are actually used in the ontology) and that the namespace url co-incides with the ontology uri  then I suppose you can conflate “namespace” and “ontology” so that you can “add axioms to a namespace”. I think that is what Josh is getting at.



But another question from me on this thread: isn’t your  proposed “option 3” exactly  the same as Armin’s option 2? Could someone kindly provide some examples here to differentiate?


All,
We desperately need some examples (or at least I do).  Feel free to explain how this would differ for Platform , the example I worked on here : https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Example



-Kerry

From: Rob Atkinson [mailto:rob@metalinkage.com.au]
Sent: Thursday, 2 February 2017 11:49 AM
To: Joshua Lieberman <jlieberman@tumblingwalls.com>; Rob Atkinson <rob@metalinkage.com.au>
Cc: Kerry Taylor <kerry.taylor@anu.edu.au>; Armin Haller <armin.haller@anu.edu.au>; public-sdw-wg@w3.org
Subject: Re: Architecture of SOSA/SSN integration

is it meaningful to "add axioms to a namespace"? I thought you would add them to an ontology, which can reuse the original namespaces.

as you pointed out earlier, we just cant add rdfs:isDefinedBy at this level of granularity.  If we want to do that, then subclassing is appropriate IMHO - but getting the data provider to care about the subclass rather than the well-known core may not be realistic...



On Thu, 2 Feb 2017 at 09:44 Joshua Lieberman <jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>> wrote:
Rob,

Just remember that there is no formal way (outside of reification) to add axioms to a new namespace because they don’t have IRI’s. All we can do is put the IRI’s of new concepts that involve them into a new namespace and make an ontology document that defines them accessible at a URL in the same namespace (such as the URL that is the same as the namespace, for example).

On Feb 1, 2017, at 5:21 PM, Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>> wrote:

I think option 3 would be better as

"SSN  imports the classes/properties defined in SOSA and introduces further axioms consistent with their meaning.  It uses a new namespace to define subclass or equivalence relations to narrow or rename terms from SOSA as required."

(or think of this as Option2 without redefining any SOSA terms)



On Wed, 1 Feb 2017 at 23:55 Kerry Taylor <kerry.taylor@anu.edu.au<mailto:kerry.taylor@anu.edu.au>> wrote:
Thank you Armin. Very much appreciated as  I could not follow the meeting.


•         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)

That proposal does rely on separate ontology files. I suspect that any sensible architecture would probably do the same, but I am worried about agreeing to something by increments without agreeing on the whole picture.  In any case I think what you saw as my objection was an objection to the statement “everyone agrees we have two uri two ontology files” (quoted from minutes) which is rather ambiguous! Furthermore the irc record confused the namespace and the ontology iri argument many times (which is not to imply the Chair was confused).


•         SOSA and SSN may use different ontology namespaces

My objection here is (a) I don’t see a need – I understand Armin’s argument about tools loading software but I have never seen another  reason in favour and it adds complexity. And, I think Maxime’s proposal solved Armin’s problem anyway– I think.


•         SSN imports SOSA
Happy with this  sometimes – but very much conditional on seeing the whole picture.  SSN should import SOSA only if SOSA is well integrated into SSN, ie that we have a good  overall design.  And not otherwise. Option 4 is an obvious counter example – SSN should *not* import SOSA in that case (which is not to imply that option 4 is a bad design).


•         SSN introduces stronger semantics, …



I am really sorry I missed that discussion entirely – it did not make it on to the IRC.  I very very much dislike 1 and 2 and I think I have probably already bored everyone  with my reasons for this. If this is what we choose to do, then ssn should certainly not import sosa as it just serves to kill ssn.



 I wonder whether 3 is meant to represent my own proposal ?  But if  so it does not capture it right, as certain elements of 4 are essential to my proposal.  Can I suggest instead  for 3 “SSN and SOSA use the same namespace for all terms. Some core terms appear in SOSA  with very simple semantics and descriptive annotations that show how it should be used.  Additional semantics that formally “narrow” the meaning and extend the expressivity are introduced in SSN. However, the SOSA “descriptive annotations” remain true  for the same terms axiomatically in SSN. Additional  descriptive comments in SSN show how to use the extended expressivity with those core terms.  SSN has no subclass or equivalence relations to core terms. “ *The really important thing here is that sosa and ssn agree on the (simplest) descriptive annotations for core terms. These descriptions hold true in the extended ssn context. That is, the simple semantics remain correct in both ontologies for common terms – but sosa generally expresses these semantics descriptively, not axiomatically*

4. not too fond of this  (more complex) but perhaps it was introduced to solve a problem with 3 that I do not see.  Given that SOSA has  very simple semantics it can probably take the role of the “separate core” of option 4 already.  My version of option 3 combined with  SOSA and SSN having the same namespace means that the problem solved by option 4 does not exist.  Although , perhaps this does solve a problem if  SOSA as it is now is considered untouchable – which would prohibit my option 3. But this can’t be true. So I guess I don’t get this option. Maybe… it is the “core” and after that sosa and ssn can define those concepts however they want, independently? So there is no interoperability between sosa and ssn? They are basically incompatible? Not fond of that!


•         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.
I don’t follow this. Does it still apply to my rephrased option 3 here? Can someone please explain? Ontologies define semantic interpretations, isolated terms do not. Would a good namespace document solve the problem here?


•         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.

It can also  be solved by my version of option 3 plus no separate namespaces – am I right? See why I prefer  only one namespace!

--Kerry


From: Armin Haller [mailto:armin.haller@anu.edu.au<mailto:armin.haller@anu.edu.au>]
Sent: Wednesday, 1 February 2017 10:40 AM
To: SDW WG Public List <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>
Subject: Architecture of SOSA/SSN integration

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