Re: Reorganizing the RDF Semantics

I fully agree with the spirit of this proposal, although I can't comment too
much on the details.  But it does reflect how I think most users of RDF want
to pick and choose which parts of the language they'd like to use.

On Tue, May 24, 2011 at 3:01 AM, Ivan Herman <ivan@w3.org> 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...
>

>From the perspective of a rule-based inference engine, with which I am most
familiar, this isn't really an issue because Pat's proposal reflects current
usage anyways.  A rule engine is typically not built with any special
knowledge of RDF, RDFS, or OWL; it just knows how to execute rules described
as Horn clauses by matching the patterns in the body against triples in a
graph and generating new triples based on the patterns in the head of the
rule.  Rules are described using some rule language, and read in (most
likely from some configuration file) at execution time.

The system might ship with some pre-defined config files describing rules
which implement RDFS, OWL-*, or other entailment regimes/profiles/languages
(SKOS, etc.) but it's up to the user to pick and choose which rules they
want to use.  They're free to mix and match between the different languages,
or write their own rules to describe custom entailments that implement their
own business logic.  The only limit is the mathematical limit that not all
possible semantic conditions are expressible as rules using Horn clauses,
but this is unrelated to the organization of the various languages.

-Alex



>
>    - 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:-)
>
>
> - 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
>
>
>
>
>
>
>