RE: Architecture of SOSA/SSN integration

Well I *think* I 100% know what Rob means in this  statement , but I might be wrong. I *think* I don’t know at all what Krzysztof means in this thread…. Of course – maybe I do!

Can we get some worked examples, please? Pretty please?

It would be just great if they worked on the Platform class  (like this https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Example) as  there is a lot of discussion under the bridge already about that as issue-88. https://www.w3.org/2015/spatial/track/issues/88


And I think it hits all the challenges if it is taken seriously, requiring a look at both what sosa needs to do and what ssn needs to do to make it work.

Kerry


From: Krzysztof Janowicz [mailto:janowicz@ucsb.edu]
Sent: Thursday, 2 February 2017 1:41 PM
To: Rob Atkinson <rob@metalinkage.com.au>; Joshua Lieberman <jlieberman@tumblingwalls.com>
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

thats fine - as long as we are not proposing mirroring sosa terms inside ssn namespace. thats the bit there seems to have been confusion over and hopefully now is resolved.

I am not 100% sure what you mean by mirroring but there may be cases where we will need subclasses.


On 02/01/2017 06:32 PM, Rob Atkinson wrote:
thats fine - as long as we are not proposing mirroring sosa terms inside ssn namespace. thats the bit there seems to have been confusion over and hopefully now is resolved.


On Thu, 2 Feb 2017 at 11:54 Krzysztof Janowicz <janowicz@ucsb.edu<mailto:janowicz@ucsb.edu>> wrote:
is it meaningful to "add axioms to a namespace"? I thought you would add them to an ontology, which can reuse the original namespaces.

This is where things become really messy as OWL has no notion of scope, context, or visibility (in contrast to object-oriented design). Phil's proposal for two files, two URLs, and two namespaces for SOSA and SSN will be a big step in avoiding some of the problems.



On 02/01/2017 04:49 PM, Rob Atkinson wrote:
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





--

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/


Semantic Web Journal: http://www.semantic-web-journal.net