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.


On Thu, 2 Feb 2017 at 11:54 Krzysztof Janowicz <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>
> 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> 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> 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]
> *Sent:* Wednesday, 1 February 2017 10:40 AM
> *To:* SDW WG Public List <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
> Webpage: http://geog.ucsb.edu/~jano/
> Semantic Web Journal: http://www.semantic-web-journal.net
>
>