- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Wed, 1 Feb 2017 18:41:05 -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: <8c2f4edb-4191-51b4-e979-70813bd28a82@ucsb.edu>
> 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) >>> <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 <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 Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net
Received on Thursday, 2 February 2017 02:41:41 UTC