W3C home > Mailing lists > Public > public-sdw-wg@w3.org > March 2017

Re: SOSA/SSN namespaces - ontology

From: Rob Atkinson <rob@metalinkage.com.au>
Date: Thu, 09 Mar 2017 00:16:26 +0000
Message-ID: <CACfF9LzE9mOj-b8VtrmcX0zVTFLkTgBvR_O9i5vFjqGnKKvTKw@mail.gmail.com>
To: Armin Haller <armin.haller@anu.edu.au>, Rob Atkinson <rob@metalinkage.com.au>, SDW WG Public List <public-sdw-wg@w3.org>
As per my comment to Kerry - referring to SSN in SOSA axioms would violate
the rules for option 8 - these are SSN axioms and should only be in SSN.
Only axioms relating to SOSA should be in sosa-owl. (and if no such axioms
exist, then this is not a problem - option 8 just collapses to option 5,
but as a general pattern for modularity, 8 is re-usable in transitive
specialisations, and i dont think that holds true for most other options.)

so I dont think the issues you mention, or Kerry's voting rationale,
actually arise for option 8.

given you have both interpreted option 8 in almost its pure antithesis, is
there something we can do to make its wording clearer?






On Thu, 9 Mar 2017 at 10:27 Armin Haller <armin.haller@anu.edu.au> wrote:

> I agree, Option 8 is technically no more difficult to implement than any
> other option. As you mentioned, probably easier than Option 1 and Option 2.
>
>
>
> However, personally I am concerned about the fact that there is an OWL
> import in SOSA, meaning if you use Protégé or some other editor, you will
> not only get all the additional axioms for a term, but these additional
> axioms may refer to terms that are defined only in SSN full and as such,
> the tool will even import SSN. This is probably something Kerry is
> concerned with and why she is thinking of a method to separate parts of the
> axioms out that refer terms that are not defined within SOSA. Which I think
> is actually impossible in this solution. The fact that at the end, in most
> tools you will end up with all axioms of SSN when you import SOSA is the
> reason that I, personally, prefer Option 1 and Option 2 (and even Option 4
> and Option 5) over Option 8.
>
>
>
> *From: *Rob Atkinson <rob@metalinkage.com.au>
> *Date: *Thursday, 9 March 2017 at 8:15 am
> *To: *SDW WG Public List <public-sdw-wg@w3.org>
> *Subject: *SOSA/SSN namespaces - ontology
> *Resent-From: *<public-sdw-wg@w3.org>
> *Resent-Date: *Thursday, 9 March 2017 at 8:16 am
>
>
>
> In SDW plenary Kerry expressed view that Option 8 looked elegant but we
> wont have time to implement.
>
>
>
> I personally dont see any qualitative difference - or if anything Options
> 5 and 8 are probably easiest to implement in time available.
>
>
>
> So I have offered to implement - as i think its simpy a matter of
> splitting SSN into tow files:
>
> sosa-owl.ttl - anything that just adds sosa axioms without mentioning SSN
>
> ssn.ttl - everything else
>
>
>
> this will IMHO only take a few minutes if SOSA + SSN in two namespaces is
> available.
>
>
>
> Looking at the ontology files however I don't see any artefact where SSN
> adds such axioms,
>
>
>
> Please point me to such a thing if it exists...
>
>
>
> If not, then I would propose:
>
>
>
> Option 8 allows us to stabilise sosa and ssn - and add the axioms to
> sosa-owl.ttl in a separate process. (i think every other option would
> require us to version at least SSN files as this work is done, but option 8
> would allow us to split out the task of axiomitisation)
>
>
>
> If it does exist, and someone points me to an artefact we all agree is the
> current modelm then I think I can whip up the option 8 implementation
> quickly :-)
>
>
>
> Rob
>
>
>
Received on Thursday, 9 March 2017 00:17:13 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 March 2017 00:17:14 UTC