- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Thu, 10 Nov 2016 08:46:40 -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: <d99040f9-5db2-f67d-41fa-ada30a76d63f@ucsb.edu>
Very true Rob. As you said, there is no simple solution here but there is still something like the Pareto principle to guide us. I believe that we can get something like the current SOSA-core to be useful to 80% of the users while only having to deal with 20% of the modeling and engineering complexity (that would be required to address those remaining 20% of users/use cases). Lets also not forget that SOSA is backed up by SSN and it is SSN that is supposed to do all the heavy lifting. Jano On 11/09/2016 10:11 PM, Rob Atkinson wrote: > I think much of the challenge is one of perspective. I've seen the > concept of Spatial Data Infrastructures go down the route of "keeping > things simple" - but from the perspective of software developers and > data publishers, not users - and we end up not having any agreed means > to find what content is behind what services or what services are > available for specific content, and having lots of metadata that only > makes sense to the particular portal design it was aimed at, and only > for the same sorts of collection sizes - with semantics stuffed into > naming conventions. Making things simple for one stakeholder usually > means making it harder for another - so we need to decide who is going > to pay. > > Rob > > > > > > On Thu, 10 Nov 2016 at 15:34 Krzysztof Janowicz <janowicz@ucsb.edu > <mailto:janowicz@ucsb.edu>> wrote: > > 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 Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net
Received on Thursday, 10 November 2016 16:47:17 UTC