W3C home > Mailing lists > Public > public-rdf-wg@w3.org > May 2011

Re: Reorganizing the RDF Semantics

From: Richard Cyganiak <richard@cyganiak.de>
Date: Wed, 25 May 2011 12:44:53 +0100
Cc: RDF Working Group WG <public-rdf-wg@w3.org>
Message-Id: <9CEEE775-DC2F-4871-A4CB-EBCD23339AB5@cyganiak.de>
To: Pat Hayes <phayes@ihmc.us>
+1 to defining interpretations in terms of a universal vocabulary.

+0.5 to “activating” semantics by use of vocabulary terms. A concern here is that implementations may want to characterize the level of inference that they support, which may not just be one of the “named entailments” like RDFS-entailment, but it might be tailored. Currently, one can refer to the named rules and say, “we support rdfs4, rdfs5, but not rdfs7.” This is a feature, and the new proposal should still allow this somehow.

As already seen, this proposal will draw objections unless the old “named entailments” are still present. A short, normative section towards the end?

My most pressing wish for the RDF 1.1 Semantics document would be a different introduction. Would this be Section -1 then? It should take a step back and discuss: Why does this document exist? Who should read it? What does it define? And especially: Who should *not* read it? How does it relate to the entire Semantic Web “building”? Writing this should be a group effort.

Regarding the entailment rules, I am not opposed to keeping them informative. There are compelling reasons for this status that can be explained in the text. They can be made more prominent: “In this section, we discuss XYZ entailment. Here is a summary of XYZ entailment, *slightly* incomplete but stated in accessible rule form for your convenience: { .... } And now here are five pages of mathematics that explain why it is so!”

Another idea, which I kind of like but it might be too radical and not practical: The entailment rules could be removed from RDF Semantics and instead put into an informative section of RDF Concepts, again with appropriate notes about their incompleteness and so on. The reasoning is that I'd like to see RDF Concepts more of a users/implementers reference document, while RDF Semantics is more about the formal foundations that explains why RDF Concepts and other RDF-related specs make sense the way they are.

Again, I'm not sure that this *actually* is a good idea but am curious what others think.


On 24 May 2011, at 05: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
Received on Wednesday, 25 May 2011 11:45:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:07 UTC