- From: Pat Hayes <phayes@ihmc.us>
- Date: Tue, 24 May 2011 23:18:31 -0500
- To: Ivan Herman <ivan@w3.org>
- Cc: RDF Working Group WG <public-rdf-wg@w3.org>, Lee Feigenbaum <lee@thefigtrees.net>
On May 24, 2011, at 2:01 AM, Ivan Herman wrote: > Pat, > > This may be very useful indeed! But I do have some comments... > > - I know I am a pain, but that is my role:-): Of course. > we have to look at the effects this may have on the deployment and standardization landscape... In particular: > > - I simply do not know (and I trust some others in the group will know that) whether various implementations of RDF stores and engines have bought into the current layering or not. Ie, do we have deployment of engines that claim: "I implement RDF interpretation and entailment but I do not implement RDFS interpretation and entailment". They might be in trouble... Yes. The regimes will still exist and the new version will of course define them exactly as they are defined now, for exactly this reason. But it will also allow other combinations to be used. > > - We have a SPARQL 1.1 Entailment Regimes' draft[1] in last call that carved up its space along the layers in the semantics document. We may have to make a decision very quickly on your proposal to possibly modify that document by, essentially, simplifying it, too. I am not saying that is impossible, but I am (again:-) concerned about a possible delay on SPARQL 1.1 (I am sure Lee will agree with me on this:-) I hope this could be resolved very quickly. I am sure that RDF can adapt smoothly to whatever SPARQL requires, actually. > > > - While we are looking at the reorganization of the RDF Semantics, there are some 'wishes' that I'd also have; these are not incompatible with what you describe. Actually, it might be even easier. > > - We know that there are certain rules/interpretations that make RDF implementations complicated and the community has come up with non-standard tricks around this. The most obvious one is the infinite number of axioms due to our friends rdf:_i. ter Horst describes the approach which is most commonly used afaik (use an upper limit for rdf:_i based on the ones used in the graph); the sparql document makes it even more restrictive in [2] by considering only those that really appear in the graph being queried. I would love to see these approaches explicitly reflected in the semantics document. Me too. ter Horst has a number of bug fixes and improvements which I plan to adopt, with suitable thanks. > > - Both for implementers and for casual readers the current Semantics document, ie, the way it is formulated, is fairly difficult to follow. Most of the readers are not familiar with the model theoretical formulation. However, all computer scientist can understand the entailment rules pretty easily, they are obvious to anyone who has written a line of computer code. In the current document those rules are fairly hidden, explicitly stated as informal; they do feel like an add-on. I think they should be way more prominent that they are now, in many respect more prominent than the interpretation constraints. You hint to that in your proposal below, actually, which makes me confident that this could be done without compromising the mathematics... Yes. I agree absolutely (and was, in spite of my spirited defense of mathematical foundational thinking, very persuaded by Richard's earlier volley to this effect.) I have a few editorial reservations, though. it is misleading to give the impression that *all* semantic constraints can be captured by rules in this way. As soon as one gets to OWL (or several of the more expressive languages) there are going to be semantic conditions that cannot be captured by Horn rules. And, I am reluctant to give the impression that RDF/S semantic constraints *must* be implemented by rules, as there are many other techniques for checking consistency or entailment which may be far more efficient in some applications. (This BTW is why all those rules are explicitly labeled as informative in the current version.) Still, I am sure we can, with careful editing, provide the clarity of rules for the programmers and also hedge them around with enough warnings to allow the inference wizards to do their exotic stuff. Pat > > Thanks! > > Cheers > > Ivan > > [1] http://www.w3.org/TR/sparql11-entailment/ > [2] http://www.w3.org/TR/sparql11-entailment/#RDFEntRegime > > > On May 24, 2011, at 06:53 , Pat Hayes wrote: > >> I would like to propose some structural changes to the RDF Semantics document, in addition to the various local changes that will be required by various decisions the WG takes, and the need to correct noted errors. I wonder what the WG thinks... >> >> In many ways the RDF semantics follows a textbook presentation of model theory. However, the way it is organized, so that each entailment regime is associated with a namespace, giving simple, RDF, RDFS and D-entailments, is *not* textbook stuff. This kind of thing just doesn't happen in textbook logics, so we were on new ground. We did it in this way largely because we couldn't think of anything else and it seemed natural to carve the space up by the URI prefix. I now think that this 'chunking' of entailments into distinct entailment regimes is not particularly useful, and probably causes more harm than good, and have a different proposal. >> >> Another, related, point is that the Semantics document follows logic textbook style in its focus on the vocabularies. The classical logical view is that a logic, such as RDF, is not itself a 'language': rather, a logical language is a set of particular names, and interpretations are always relative to such a set. We called these vocabularies. I now think that this is not really appropriate for a Web language such as RDF (or indeed OWL or RIF or any of the others); rather, we should always have a single 'vocabulary' consisting of all possible Web names, ie *all* IRIs. A web interpretation is then a mapping from all possible IRIs to elements of a universe, so this universal vocabulary does not need to be mentioned more than once. This eliminates the need to speak of RDF-interpretations, RDFS-interpretations, etc.; they are all just interpretations. (An RDF interpretation is now an interpretation which satisfies all the RDF semantic conditions, and similarly for the others; but this is no longer a different *sort* of interpretation.) This simplifies and unifies the semantic treatment, and it also gets rid of some odd technical glitches associated with empty vocabularies. >> >> So, the idea is that we will list all the semantic conditions, just as we do now (though see below) but instead of grouping them into distinct entailment regimes, we will associate them with the vocabulary that is used to state them. We simply say that if you use any of the rdf: or rdfs: URIs in your graph, then you are buying into (that is, you agree to accept the truth of) all the semantic conditions that apply to your vocabulary items, ie all the axioms and rules that are stated using only the vocabulary items you use. For example, if you use rdfs:subClass, then you are agreeing that it is transitive, since this rule only uses rdfs:subClass. Similarly, if you use any RDF literal syntax, then you are buying into the semantic conditions that apply to whatever type URIs you are using, and so on. We can still define the RDF- and RDFS- entailment regimes, but these would now be in an appendix rather than being the overall organizing backbone of the whole semantic system. (Simple entailment will always be a well-defined option, by the way: it is the entailment that you get when you ignore all vocabulary semantic conditions.) >> >> This has the merits of simplicity and uniformity, but more importantly, it allows the semantic commitment made by an RDF user to be tailored to the particular pieces of RDF/S vocabulary she wants to use, without necessarily buying into a whole entailment regime; and it means that the question, of which entailment regime is relevant (should we be doing RDF or RDFS reasoning?) is now avoided, or maybe answered in a uniform and automatic way. An example is the recent request to include XSD datatyping without being forced to buy into RDFS entailment: this would follow automatically in this new regime, simply by using XSD vocabulary in literals but not as class names. >> >> Obviously, the devil is in the details, but I would be interested in feedback (positive or negative) before getting too embroiled in those. >> >> I would also like to adopt a more 'regular' way to express the various semantic conditions. Right now some of them are written as model-theoretic constraints on interpretations, others as 'axioms' and others as entailment 'rules' . There is no real reason to have things this mixed, and I think it would be easier if all the conditions were presented uniformly, perhaps in both model-theoretic and axiom/rule styles, in different tables, but in a uniform format throughout. >> >> Pat >> >> ------------------------------------------------------------ >> IHMC (850)434 8903 or (650)494 3973 >> 40 South Alcaniz St. (850)202 4416 office >> Pensacola (850)202 4440 fax >> FL 32502 (850)291 0667 mobile >> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes >> >> >> >> >> >> > > > ---- > Ivan Herman, W3C Semantic Web Activity Lead > Home: http://www.w3.org/People/Ivan/ > mobile: +31-641044153 > PGP Key: http://www.ivan-herman.net/pgpkey.html > FOAF: http://www.ivan-herman.net/foaf.rdf > > > > > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Wednesday, 25 May 2011 04:19:02 UTC