On 5/24/2011 3: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:-): 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...
>
> - 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.
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
>
>
>
>
>
>