- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Sat, 12 Nov 2016 07:32:38 -0800
- To: Rob Atkinson <rob@metalinkage.com.au>, Kerry Taylor <kerry.taylor@anu.edu.au>, "Simon.Cox@csiro.au" <Simon.Cox@csiro.au>, "antoine.zimmermann@emse.fr" <antoine.zimmermann@emse.fr>, Armin Haller <armin.haller@anu.edu.au>, "jano@geog.ucsb.edu" <jano@geog.ucsb.edu>, "jlieberman@tumblingwalls.com" <jlieberman@tumblingwalls.com>
- Cc: "public-sdw-wg@w3.org" <public-sdw-wg@w3.org>
- Message-ID: <61ecb20b-2c48-8d95-4760-1451a4b1be8b@ucsb.edu>
> IMHO its still a significant choice as to whether we include RDFS than > can be inferred from OWL or ask users to perform OWL reasoning if they > want to understand it as RDFS classes. Agreed. But Antoine already confirmed what we said before. Using owl:class will not cause any problems for RDFS reasoners. If we want to be extra sure we will declare owl:class and rdfs:class at the same time. The same is true for inverse properties, they do not cause any harm from an RDFS-only perspective. This leaves us the domainincludes and rangeincludes properties that we already know will not cause harm and this is basically it. At least for what we have modeled so far. > +1 to putting this to bed and working on the content Fantastic! I think (and hope) that we are all more or less on the same page as far as contents are concerned as those have been online since the spring. Our next steps should be to polish what we have, clarify the outstanding issues that remain, and then make sure we can get those implementations that we will need for the rectrack. Looking forward to the next steps. Krzysztof On 11/11/2016 11:33 PM, Rob Atkinson wrote: > +1 to putting this to bed and working on the content - but until we > are all on the same page it is proving a distraction - hence my > attempt to lay out the options so i at least understand the differeng > points of view and assumptions I am detecting. > > IMHO its still a significant choice as to whether we include RDFS than > can be inferred from OWL or ask users to perform OWL reasoning if they > want to understand it as RDFS classes. Because we get sidetracked by > whether we are going to allow or disallow stuff we keep failing to > reach a consensus on this very simple matter. Yes its only packaging > for some of us, but if you are not operating in an OWL tools > environment I think you will face an unnecessary barrier. > > Whether to put owl semantics in a separate module which imports the > base is another matter - this shouldnt affect OWL tools. We can also > use content-negotiation so if you ask for OWL you get the OWL package, > but if you ask for RDF you get the core, with some sort of link > (rdfs:seeAlso?) to the OWL. I'm agnostic about this, but suspect if we > want to have different flavours of OWL (RL, DL etc) we'll need to > analyse the requirement some more. > > Rob > > > On Sat, 12 Nov 2016 at 16:34 Krzysztof Janowicz <janowicz@ucsb.edu > <mailto:janowicz@ucsb.edu>> wrote: > > Hi, > > I am not sure what this all means, but I have to say that I wonder > why we are turning something that is really simple into an > unbelievable complicated issue. > > Why, for instance, would we want to restrict SOSA-Core to barely > using RDFS? We already have many, many people that voiced their > support for explicitly declaring inverse relations? > > We should be talking about whether we agree on the concepts and > their interpretations in SOSA-core. > > Best, > Krzysztof > > > > On 11/11/2016 09:20 PM, Kerry Taylor wrote: >> >> I think Rob’s (2) below is the only thing that makes any sense, >> especially in the context of the decision at the F2f in Lisbon >> two have exactly 2 modules – core and ssn-minus-dul. (with the >> dul alignment also available, but not part of it). >> >> I rather like Rob’s(1) but it is much too late to get there from >> here. I can live with Rob’s(3). >> >> But I am not sure I understand this: >> >> ØNote also that if we publish two modules: sosa.OWL-DL >> and sosa.RDFS, and the RDFS is generated from the OWL, then the >> fact that RDFS does not have an import makes option that nearly >> equivalent to option #2 (the OWL does not need to import the >> RDFS, although it could do so) >> >> Issue-72 >> >> *From:*Krzysztof Janowicz [mailto:janowicz@ucsb.edu] >> *Sent:* Thursday, 10 November 2016 3:34 PM >> *To:* Rob Atkinson <rob@metalinkage.com.au> >> <mailto:rob@metalinkage.com.au>; Kerry Taylor >> <kerry.taylor@anu.edu.au> <mailto:kerry.taylor@anu.edu.au>; >> Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>; >> antoine.zimmermann@emse.fr <mailto:antoine.zimmermann@emse.fr>; >> Armin Haller <armin.haller@anu.edu.au> >> <mailto:armin.haller@anu.edu.au>; jano@geog.ucsb.edu >> <mailto:jano@geog.ucsb.edu>; jlieberman@tumblingwalls.com >> <mailto:jlieberman@tumblingwalls.com> >> *Cc:* public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org> >> *Subject:* Re: rdfs:class versus owl:class in SOSA-Core >> >> Hi Rob, >> >> I think this goes back to the issue I raised here: >> https://lists.w3.org/Archives/Public/public-sdw-wg/2016Nov/0065.html >> . Lets discuss our modeling choices first and then decide about >> representational choices. The solution we have now is just fine >> and so far nobody was able to bring up any other argument that >> would point to any problem (assuming we add both owl:class and >> rdfs:class as extra level of safety). >> >> SOSA -core is supposed to be a conceptually simple, not based on >> a 'simple' representation language. >> >> Best, >> Krzysztof >> >> >> >> On 11/09/2016 08:03 PM, Rob Atkinson wrote: >> >> my opinion is that I'm happy to have owl constructs as long >> as the rdfs that would be entailed by OWL reasoning, but not >> RDFS reasoning, is materialised, and hence the user is not >> expected to use an OWL reasoner. There seems to be a >> consensus (or at least no counter-arguments to this specific >> policy ACAICT) >> >> I am therefore agnostic as whether all OWL is in a extension >> model which supports OWL-DL (?) reasoning - and is part of >> the normative semantics. I guess the question is whether >> there is a need for a subset of OWL semantics which imposes a >> low burden an OWL reasoner (a simple core). Others with more >> experience need to weigh in and document the subset and we >> can then vote if we are happy to include it in the core. >> >> Kerry has made the useful point that expectations are raised >> when a user finds OWL constructs. Perhaps that can be managed >> by clear enough documentation that all RDFS semantics implied >> by such OWL is materialised. >> >> There is a possible lower level of commitment - in that in >> the core terms are just defined using SKOS, without any form >> of class model - but I think we all feel that the world is >> used to simple RDFS models and we could use that as a >> moderately expressive baseline. >> >> So I see the choice is between: >> >> 1) something like SKOS Concepts to "reserve" resource names >> and attach documentation >> >> 2) RDFS only + OWL module that imports it >> >> 3) RDFS inc. "cheap to process OWL" + OWL-DL module that >> imports it >> >> 4) OWL-DL only >> >> 5) OWL-DL with entailed RDFS >> >> 6) something I've missed :-) >> >> Note also that if we publish two modules: >> >> sosa.OWL-DL and sosa.RDFS, and the RDFS is generated from >> the OWL, then the fact that RDFS does not have an import >> makes option that nearly equivalent to option #2 (the OWL >> does not need to import the RDFS, although it could do so) >> >> I propose we get this list of options nailed down so we can >> identify which flavour we are talking about in future, and >> then if we cant get a consensus quickly document pros and >> cons, and specifically anything we might break for users. (As >> an example I personally think #4) (OWL-DL only) breaks it for >> RDFS-only based reasoning) >> >> Rob Atkinson >> >> On Thu, 10 Nov 2016 at 12:55 Kerry Taylor >> <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>> wrote: >> >> And therein lies another dragon -- or an elephant? >> >> In ssn a ssn:MeasurementCapability is not defined with >> domain/range. Instead it is defined via a local >> allvaluesfrom restriction on Sensor. So certainly this >> following holds: >> >> > ?x :hasMeasurementCapability ?y . >> > I cannot conclude that ?y is a :MeasurementCapability >> >> One of the many promises of the "simple" core is that it >> is simpler than full ssn in the sense that it makes >> weaker ontological commitments (see the notion of >> "vertical modularisation" in the FPWD). >> >> So this automatically forbids rdfs:domain and rdfs:range >> in this case and similarly most others. Or otherwise it >> forbids one of many other broadly agreed goals. >> >> >> Having said that, which remains true in general, >> hasMeasurementCapability in particular is not currently >> proposed to exist at all in sosa-core >> https://github.com/w3c/sdw/blob/gh-pages/ssn/rdf/sosa.ttl. >> So there may be no issue there. >> >> However the same principle should indeed apply to >> observedProperty, for example, which does occur in the core. >> >> -----Original Message----- >> From: Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au> >> [mailto:Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>] >> Sent: Thursday, 10 November 2016 12:19 PM >> To: antoine.zimmermann@emse.fr >> <mailto:antoine.zimmermann@emse.fr>; janowicz@ucsb.edu >> <mailto:janowicz@ucsb.edu>; Armin Haller >> <armin.haller@anu.edu.au >> <mailto:armin.haller@anu.edu.au>>; jano@geog.ucsb.edu >> <mailto:jano@geog.ucsb.edu>; jlieberman@tumblingwalls.com >> <mailto:jlieberman@tumblingwalls.com>; Kerry Taylor >> <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>> >> Cc: public-sdw-wg@w3.org <mailto:public-sdw-wg@w3.org> >> Subject: RE: rdfs:class versus owl:class in SOSA-Core >> >> > something really wrong in the name of the property! >> Or, alternatively there ought to be a rdfs:range axiom. >> >> An owl:ObjectProperty without a rdfs:range axiom is >> usually be missing the most significant part of the >> semantics. I generally add these as a matter of course >> (not so for rdfs:domain). As Jano pointed out, semantics >> shouldn't depend on labels. >> >> Simon >> >> -----Original Message----- >> From: Antoine Zimmermann >> [mailto:antoine.zimmermann@emse.fr >> <mailto:antoine.zimmermann@emse.fr>] >> Sent: Thursday, 10 November 2016 10:06 AM >> To: janowicz@ucsb.edu <mailto:janowicz@ucsb.edu>; Armin >> Haller <armin.haller@anu.edu.au >> <mailto:armin.haller@anu.edu.au>>; Krzysztof Janowicz >> <jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>>; Joshua >> Lieberman <jlieberman@tumblingwalls.com >> <mailto:jlieberman@tumblingwalls.com>>; Cox, Simon (L&W, >> Clayton) <Simon.Cox@csiro.au> >> <mailto:Simon.Cox@csiro.au>; Kerry Taylor >> <kerry.taylor@anu.edu.au <mailto:kerry.taylor@anu.edu.au>> >> Cc: SDW WG Public List <public-sdw-wg@w3.org >> <mailto:public-sdw-wg@w3.org>> >> Subject: Re: rdfs:class versus owl:class in SOSA-Core >> >> On 09/11/2016 23:46, Krzysztof Janowicz wrote: >> >> >> >> [...] >> >> >> -rdfs:domain and rdfs:range >> >> >> >> Please use these whenever relevant. [...]. You can't >> go wrong with them. >> > >> > This is the only part of your email where I would >> strongly disagree >> > (well, depending on what you mean by 'whenever >> relevant' :-)) for the >> > reasons we discussed here before and that others made >> when developing >> > other ontologies. This is not to say that using them is >> 'wrong' in >> > some sense but that they have to be handled with great >> care. >> >> On this, I know what you mean. I've read the arguments >> that were written at some point in the SSN draft. I know >> that it is wise to avoid systematic domains and ranges >> that could be too restrictive. >> >> But I think that this went too far with things like: >> >> :hasMeasurementCapability a owl:ObjectProperty . >> :MeasurementCapability a owl:Class . >> >> and no range for :hasMeasurementCapability. If, whenever >> I find: >> >> ?x :hasMeasurementCapability ?y . >> >> I cannot conclude that ?y is a :MeasurementCapability, >> then there is something really wrong in the name of the >> property! Or, alternatively there ought to be a >> rdfs:range axiom. >> >> >> --AZ >> >> >> >> > >> > Best, >> > Krzysztof >> > >> > >> > >> > On 11/09/2016 01:15 PM, Antoine Zimmermann wrote: >> >> On 09/11/2016 00:20, Armin Haller wrote: >> >>> Hi Krzysztof, >> >>> >> >>> Thanks for your detailed explanations below! >> >>> >> >>> Just to clarify, the intention in the meeting to go >> through a list >> >>> of what constructs should be in SOSA (as thankfully >> proposed by >> >>> Josh) was to be incremental. I was planning to >> incrementally go >> >>> through the list of constructs that are either >> already in our >> >>> current SOSA proposal or could be imagined to be in >> it and vote on >> >>> them. Some, of course have implications, if we decide on >> >>> owl:inverseOf in our next meeting, we will not be in >> RDFS entailment. >> >> >> >> I was not at the meeting, so I may have missed >> something, but what is >> >> the rationale for forbidding certain constructs? If >> there is an >> >> owl:inverseOf in the ontology, the RDFS reasoners >> won't care. Nobody >> >> who's not using/interested in owl:inverseOf will care. >> >> >> >> However, in the case of owl:inverseOf, I don't think >> it is a question >> >> of whether we want to use the construct or not. It is >> a question of >> >> deciding whether we allow ourselves to define both a >> property and its >> >> inverse. If we have properties like ex:hasChild and >> ex:hasParent, it >> >> would be silly not to make explicit the inverse >> relationship. If the >> >> decision is about not having both a property and its >> inverse, then >> >> the need to use or not owl:inverseOf is only an inevitable >> >> consequence of the other decision. >> >> >> >> >> >>> If we are already in OWL, then of course it would >> make sense to use >> >>> owl:Class, although we do not have to. Therefore, >> again a vote on >> >>> owl:Class thereafter. >> >> >> >> I don't see a reason not to. Not having owl:Class >> declaration has >> >> noticeable consequences. For instance, it always >> troubles me that >> >> Protégé cannot display the Dublin Core properties and >> classes. It >> >> also troubles me that the DC terms cannot be imported >> with standard >> >> owl:imports, because of the lack of owl class, owl >> properties >> >> declarations. >> >> >> >> >> >>> I can think of the following list to vote on in our >> next meeting, >> >>> incrementally. And we stopped at owl:inverseOf this >> meeting I just >> >>> saw in the minutes. >> >>> >> >>> -rdfs:class >> >> >> >> see above and related emails. >> >>> >> >>> -owl:inverseOf >> >> >> >> see above. >> >>> >> >>> -owl:AnnotationProperty >> >>> >> >>> - owl:ObjectProperty >> >> >> >> owl:AnnotationProperty, owl:ObjectProperty and >> owl:DatatypeProperty, >> >> like owl:Class, do not add expressiveness to the >> language. However, >> >> they help OWL tools figuring out what the terms are. >> >> >> >> FWIW, in OWL 2 RDF-based semantics, owl:ObjectProperty >> is equivalent >> >> to rdf:Property. owl:AnnotationProperty and >> owl:DatatypeProperty are >> >> both subClassOf rdf:Property. >> >> >> >>> >> >>> -owl:Class >> >> >> >> see above. >> >> >> >>> >> >>> -rdfs:domain and rdfs:range >> >> >> >> Please use these whenever relevant. When used with an >> atomic class, >> >> they are fully supported by RDFS, OWL 2 EL, OWL 2 QL, >> OWL 2 RL, OWL 2 >> >> DL, OWL 2 Full, ter Horst semantics, RDFS++. You can't >> go wrong with >> >> them. >> >> >> >>> >> >>> -rdfs:subClassOf >> >> >> >> Come on! Do we need to vote on this one? >> >> >> >>> >> >>> - owl:Restriction >> >> >> >> There are many forms of restrictions, each one should >> be considered >> >> individually. I don't see much reason to forbid >> ourselves to use any >> >> of them because anyone can just ignore those they >> don't like. >> >> However, they should be used sensibly because we >> should not prevent >> >> use cases that we have not foreseen. I'd prefer an >> ontology that has >> >> very little restrictions with precise documentation to >> prevent >> >> misusing the terms, rather than an overly restrictive >> one. Look at >> >> schema.org <http://schema.org>: painfully >> non-restrictive, delightfully useful. >> >> >> >> >> >> --AZ >> >> >> >>> >> >>> Please do think about these and if you think they >> should or should >> >>> not be in the core or if there is anything else we >> desperately would need. >> >>> >> >>> Kind regards, >> >>> Armin >> >>> >> >>> *From: *Krzysztof Janowicz <jano@geog.ucsb.edu >> <mailto:jano@geog.ucsb.edu>> >> >>> *Date: *Wednesday, 9 November 2016 at 10:01 am >> >>> *To: *Joshua Lieberman <jlieberman@tumblingwalls.com >> <mailto:jlieberman@tumblingwalls.com>>, Simon Cox >> >>> <Simon.Cox@csiro.au> <mailto:Simon.Cox@csiro.au>, >> Kerry Taylor <kerry.taylor@anu.edu.au >> <mailto:kerry.taylor@anu.edu.au>>, Armin >> >>> Haller <armin.haller@anu.edu.au >> <mailto:armin.haller@anu.edu.au>> >> >>> *Cc: *SDW WG Public List <public-sdw-wg@w3.org >> <mailto:public-sdw-wg@w3.org>> >> >>> *Subject: *rdfs:class versus owl:class in SOSA-Core >> >>> >> >>> Hi, >> >>> >> >>> Sorry for being so picky about this during our >> meeting but I do not >> >>> want us to take decisions that have consequences that >> we can not yet foresee. >> >>> >> >>> To the best of my knowledge (and please correct me if >> I am wrong): >> >>> >> >>> Under the semantics of OWL1, rdfs:class and owl:class >> are only >> >>> equivalent for OWL-Full. For OWL-DL (and OWL-Lite) >> owl:class is a >> >>> subclass of rdfs:class. >> >>> >> >>> This means that every valid document in OWL will be a >> valid document >> >>> in RDFS, however *not* every rdfs:class is an >> owl:class. I do not >> >>> want us to end up in OWL-Full because of this. >> >>> >> >>> For OWL2, I found this: 'owl:Class rdfs:subClassOf >> rdfs:Class . " >> >>> (https://www.w3.org/TR/owl2-rdf-based-semantics/). >> Things may be >> >>> more complicated here due to OWL2 punning and they >> may well turn out >> >>> to be equivalent, I will check this later. >> >>> >> >>> If we decide to restrict ourself to only using RDFS >> for SOSA-core, >> >>> and I am not in favor of this, then we may have to go >> with rdfs:class. >> >>> However, we have not yet taken this decision and have >> also not >> >>> discussed which axioms and language to use for SSN. >> As Sosa-core and >> >>> SSN will be aligned, this may have more consequences >> that we should >> >>> consider. It also seems like many of us are in favor >> of using >> >>> inverseOf, so we would be using OWL (and its formal >> semantics) >> >>> anyway. Note that this does not do any harm to an >> RDFS-only >> >>> tool/user as for those the inverseOf axiom will >> simply have no >> >>> formal semantics. Still all other triples that use >> both relations will still be just fine. >> >>> >> >>> Given the subclasssing, I do not see any problems >> using owl:class, >> >>> but we may accidentally end up in OWL-full or with being >> >>> incompatible to the standards if we opt for >> rdfs:class. Again, I am happy to be corrected. >> >>> At least, I do not see harm in simply using owl:class. >> >>> >> >>> Finally, and from very pragmatic point of view: >> ontologies that are >> >>> under very heavy use such as the DBpedia ontology >> simply use >> >>> owl:class and I have not yet seen any issues or >> complaints about that. See, for >> >>> example, http://dbpedia.org/ontology/City "dbo:City >> rdf:type >> >>> owl:Class ." The same is true for the goodrelations >> ontology and so >> >>> forth (but I admit that this is due to the more complex >> >>> axiomatization they use). >> >>> >> >>> I hope this will start a productive discussion. >> >>> >> >>> Thanks for reading, >> >>> >> >>> Krzysztof >> >>> >> >> >> > >> > >> >> >> -- >> 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 <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 Saturday, 12 November 2016 15:33:16 UTC