- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Wed, 1 Feb 2017 16:54:36 -0800
- 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" <public-sdw-wg@w3.org>
- Message-ID: <06f06706-dcc7-655b-7fbe-a617dcafeb78@ucsb.edu>
> 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) >> <https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017%29> >> >> 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) >> <https://www.w3.org/2015/spatial/wiki/Proposals_for_rewriting_SSN#Compromise_Proposal_6_made_by_Kerry_January_2017%29> >> >> ·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
Received on Thursday, 2 February 2017 00:55:13 UTC