- From: Ivan Herman <ivan@w3.org>
- Date: Tue, 24 May 2011 09:25:22 +0200
- To: Lee Feigenbaum <lee@thefigtrees.net>
- Cc: Pat Hayes <phayes@ihmc.us>, RDF Working Group WG <public-rdf-wg@w3.org>
On May 24, 2011, at 09:17 , Lee Feigenbaum wrote: > On 5/24/2011 3:01 AM, Ivan Herman wrote: <snip/> >> >> - 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 read Pat's proposal as a presentation change which would still define these regimes, so this does not concern me. Ah. I reread Pat's mail: [[[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.) ]]] which may give your right. I am happy to be proven wrong! (In this case:-) Ivan > > Lee > >> >> - 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. >> >> - 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... >> >> 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 >> >> >> >> >> >> ---- 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
Received on Tuesday, 24 May 2011 07:23:22 UTC