- From: Krzysztof Janowicz <janowicz@ucsb.edu>
- Date: Wed, 9 Nov 2016 09:06:27 -0800
- To: Claus Stadler <cstadler@informatik.uni-leipzig.de>, SDW WG Public List <public-sdw-wg@w3.org>
- Cc: Joshua Lieberman <jlieberman@tumblingwalls.com>, Rob Atkinson <rob@metalinkage.com.au>, Krzysztof Janowicz <jano@geog.ucsb.edu>, Simon Cox <Simon.Cox@csiro.au>, Kerry Taylor <kerry.taylor@anu.edu.au>, Armin Haller <armin.haller@anu.edu.au>
- Message-ID: <2f33dec1-852e-e5d7-fb3d-860a598b5490@ucsb.edu>
> > We could just add the subClassOf triple to the Sosa ontology file, and > it would work out of the box with RDFS reasoners. As RDFS reasoners > would ignore owl semantics anyway, I don't see that this imposes *any* > restriction on RDFS inferences. If you want, you can still state > > "A a owl:Class . B a owl:Class . B a A" - and an RDFS reasoner is not > supposed to complain > > > *** So using [the symbol] owl:Class in the ontology imposes > *absolutely* no restrictions on *pure* RDFS reasoning. *** Yes, THANKS! > > For instance, the sosa ontology currently sates about > sosa-core:Platform:"A platform carries at least one Sensor, Actuator, > or Sampling Device" > > So this could already be rephrased as a owl restriction using > owl:someValuesFrom. > This is where I disagree as it takes us to an entirely different level of ontological commitments that we originally wanted to avoid for SOSA-core. Of course, we can revisit this but it would lead to major changes in what SOSA-core would be and why it would be useful. The (initial) idea of SOSA-Core was to have a core, lightweight version that avoids strong ontological commitments and is targeting the typical schema.org kind of audience. > I agree with Danh's comment from yesterday's call, that if everything > is just an annotation, we are handing many problems which I think we > intent to solve back to the developers. Yes and no. I would agree in the case of inverse properties and therefore would like to use them directly but would disagree for domain and range as discussed in many previous mails before. Global domains and ranges are very powerful and dangerous concepts that we decided to avoid and the schema.org versions do not carry any formal semantics (as you rightfully pointed out) so they are just a more formal kind of documentation for the users. This has turned out to be very useful and this is why schema.org introduced them. So, I do not see any risk but many benefits (just talking about domainIncludes and rangeIncludes here, and I agree with the rest of what was said about overusing annotation properties). > sosa-core:ActuatorOrSensor . This puts semantics into labels, I would try to avoid that at all costs. > Also, having written a faceted browser myself, I agree with Krzysztof > that in this setting, standard inverses would be very beneficial. +1 > So from this perspective, it would have been extremely useful, if the > DCAT standard stated: > > "These are predefined inverse properties. Tools *may* support them, > however in order for your data to be usable without reasoning, the > usage of the non-inverse properties is endorsed." > > In fact, with this statement, tools could just apply transformation of > the inverses in a preprocessing step without requiring reasoning. > Very nice example! [I have to admit that I have not really used DCAT before.] Krzysztof On 11/09/2016 07:55 AM, Claus Stadler wrote: > > Hi, my 2cents on the issues owl:Class, meta properties and inverse > properties > > > About owl:Class vs rdfs:Class > > ================== > > We could just add the subClassOf triple to the Sosa ontology file, and > it would work out of the box with RDFS reasoners. As RDFS reasoners > would ignore owl semantics anyway, I don't see that this imposes *any* > restriction on RDFS inferences. If you want, you can still state > > "A a owl:Class . B a owl:Class . B a A" - and an RDFS reasoner is not > supposed to complain > > > *** So using [the symbol] owl:Class in the ontology imposes > *absolutely* no restrictions on *pure* RDFS reasoning. *** > > The thing we need to be careful about is, that we do not [want to] > make use of this "classes instances of other classes" feature > ourselves in the standard. > > Conversely, using owl:Class enables users (and us) to provide further > restrictions. > > > For instance, the sosa ontology currently sates about > sosa-core:Platform:"A platform carries at least one Sensor, Actuator, > or Sampling Device" > > So this could already be rephrased as a owl restriction using > owl:someValuesFrom. > > > Object vs Annotation Properties > > =================== > > In case this topic has been discussed in depth in other mails, I > apologies beforehand :) > > I agree with Danh's comment from yesterday's call, that if everything > is just an annotation, we are handing many problems which I think we > intent to solve back to the developers. > > > The meta statements are very soft, and don't have any semantics - right? > > sosa-core:hostedBy > > meta:domainIncludes sosa-core:Actuator ; > meta:domainIncludes sosa-core:Sensor ; > meta:rangeIncludes sosa-core:Platform ; > > So I think there would be no harm to rephrase these kinds of > annotations using proxy RDFS classes in order to work around the > domain/range intersections: > > sosa-core:ActuatorOrSensor a owl:Class . > > sosa-core:Actuator rdfs:subClassOf sosa-core:ActuatorOrSensor. > > sosa-core:Sensor rdfs:subClassOf sosa-core:ActuatorOrSensor. > > sosa-core:hostedBy rdfs:domain sosa-core:ActuatorOrSensor . > > > Maybe the name ActuatorOrSensor is too strict, and a term such as > sosa-core:InputOutputThing / ActiveComponent / whatever would be more > open to possibly custom future additions. > > > So this would transform the rather informal meta:* properties into a > property RDFS model, and a reasoner could infer that anything making > use of the hostedBy property is an ActuatorOrSensor instance rather > than not inferring anything at all. I think this kind of reasoning > would already be useful if someone asks: So according to the data, > what ActuatorOrSensors / ActiveComponents actually are there in the > company? > > > Inverse Properties > > =========== > > An anecdote about an issue I encountered with DCAT: > > I open my text editor to edit a DCAT turtle file about datasets used > in a project, and I want to manually state that I am hosting another > SPARQL distribution of the DBpedia dataset on one of my domains. Now I > make up some URI to identify my record (ex:dist-my-dbpedia) about the > distribution and state that this is a distribution of DBpedia (in ER > that would be a foreign key relation from the "Distribution" entity > referencing its owning "Dataset"). Oops, that's not standard DCAT, > because distributionOf is not defined - only dcat:distribution. So I > am actually required to locate and update the dataset resource as well. > > So from this perspective, it would have been extremely useful, if the > DCAT standard stated: > > "These are predefined inverse properties. Tools *may* support them, > however in order for your data to be usable without reasoning, the > usage of the non-inverse properties is endorsed." > > In fact, with this statement, tools could just apply transformation of > the inverses in a preprocessing step without requiring reasoning. > > Also, having written a faceted browser myself, I agree with Krzysztof > that in this setting, standard inverses would be very beneficial. > > > So for issue 72, my vote also goes to "The pair is to be related by > an owl:InverseOf declaration". > > > Best regards, > > Claus > > > On 09.11.2016 15:01, Kerry Taylor wrote: >> >> *From:*Kerry Taylor >> *Sent:* Wednesday, 9 November 2016 11:19 PM >> *To:* 'Joshua Lieberman' <jlieberman@tumblingwalls.com> >> *Subject:* RE: rdfs:class versus owl:class in SOSA-Core >> >> ØSince owl:Class rdfs:subClassOf rdfs:Class, then any owl class is >> also an rdfs class. However, not every rdfs class is an owl class. >> >> True – but it takes an owl reasoner to know that --- an rdfs reasoner >> is blissfully ignorant of what an owl:Class is, hence the need for >> :myClass a rdfs:Class (or some other way of having the same effect). >> >> I think we need to be very, very clear that an owl reasoner is not >> needed for working with the ssn core. By far the easiest way of >> making that clear is to avoid owl terms entirely in the core. >> >> Sure—you can assert owlish things like “:myClass a owl:Class” in >> the core that an rdfs reasoner can ignore and you just get the rdfs >> entailments – but if you only want rdfs entailments then what could >> be the possible utility in asserting such owlish things? Why go to so >> much trouble to only confuse the consumers? Schema.org tackles this >> by making up owl: lookalikes – things that are claimed **informally** >> to have the semantics of owl or something very close but are not >> owl. I tend to think that is the worst of all worlds, but others >> would disagree I am sure. >> >> And if we **do** want owl reasoning to be needed for working with the >> core --- then what part? And why? Here we are struggling with the >> problem “ssn is too complex because you need an owl reasoner” and we >> are suggesting that an answer like “Hey look at our simple core --- >> it has significant owl: terms in it but you don’t have to use a >> reasoner if you don’t want to and you can’t really tell in your >> queries whether it has been used or not, nor can you tell whether >> you should, for your publishing, be using a real reasoner or some >> other extra non-owl thing that implements just the little bit of owl >> we chose to stick in the ontology – but hey look it is **really** >> simple “. >> >> Yes, I am wandering all over issue-72 here. And I am convincing >> myself that we should stick purely to rdf(s) in the core. If we can’t >> do that, then we should be very, very clear about what part of owl we >> are using. And to do that it had better be a named owl sublanguage. >> >> --Kerry >> >> *From:*Joshua Lieberman [mailto:jlieberman@tumblingwalls.com] >> *Sent:* Wednesday, 9 November 2016 4:58 PM >> *To:* Rob Atkinson <rob@metalinkage.com.au >> <mailto:rob@metalinkage.com.au>> >> *Cc:* Krzysztof Janowicz <jano@geog.ucsb.edu >> <mailto:jano@geog.ucsb.edu>>; 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>>; 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 >> >> Since owl:Class rdfs:subClassOf rdfs:Class, then any owl class is >> also an rdfs class. However, not every rdfs class is an owl class. >> >> On Nov 8, 2016, at 6:47 PM, Rob Atkinson <rob@metalinkage.com.au >> <mailto:rob@metalinkage.com.au>> wrote: >> >> Correct me if I'm wrong here: >> >> :myClass a owl:Class, rdfs:Class >> >> is the same as >> >> :myClass a owl:Class >> >> if you are using OWL reasoning. >> >> If you are using RDFS reasoning (and tools like RDF4J support >> this) - then these statements are not the same - and only the >> first one helps you with any RDFS reasoning. >> >> So why cant we just use the first form? >> >> The principle would be that the "core" would not _require_ OWL >> reasoning to provide a RDFS model. It doenst mean we don't model >> in OWL, just that we take on the responsibility of materialising >> OWL entailments sufficient to allow any RDFS entailments. (Thats >> what I mean about a "contract" with the user - being explicit >> about what entailments are theer responsibility >> >> Note that is we state: >> >> :myClass a rdfs:Class >> >> and say: >> >> :myClass owl:equivalentClass eg:yourClass >> >> then if you use OWL reasoning you get >> >> :myClass a owl:Class, rdfs:Class >> >> because >> >> owl:equivalentClass rdfs:domain owl:Class >> >> owl:equivalentClass rdfs:range owl:Class >> >> Therefore, if you don't explicitly state its an owl:Class you can >> still do OWL reasoning and you have lost nothing - but if you >> don't explicity state its and RDFS class then you wont get the >> full RDFS expressible semantics without OWL reasoning. >> >> statements such as owl:inverseOf are just documentation for RDFS >> interpretations, and perhaps "do no harm"? >> >> am I missing something here? >> >> note that we can then have sosa-owl-dl and other OWL flavours as >> vertical modules that require OWL reasoning to be fully understood. >> >> Rob Atkinson >> >> On Wed, 9 Nov 2016 at 10:01 Krzysztof Janowicz >> <jano@geog.ucsb.edu <mailto:jano@geog.ucsb.edu>> wrote: >> >> 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 Webpage: http://geog.ucsb.edu/~jano/ Semantic Web Journal: http://www.semantic-web-journal.net
Received on Wednesday, 9 November 2016 17:07:05 UTC