- From: Rob Atkinson <rob@metalinkage.com.au>
- Date: Thu, 09 Mar 2017 00:16:26 +0000
- To: Armin Haller <armin.haller@anu.edu.au>, Rob Atkinson <rob@metalinkage.com.au>, SDW WG Public List <public-sdw-wg@w3.org>
- Message-ID: <CACfF9LzE9mOj-b8VtrmcX0zVTFLkTgBvR_O9i5vFjqGnKKvTKw@mail.gmail.com>
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