W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

Re: Re 2: [TF-ENT] RDFS entailment regime proposal

From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Date: Mon, 28 Sep 2009 14:06:16 +0100
Message-ID: <492f2b0b0909280606n681edf76if0d3a73b56ce6dd6@mail.gmail.com>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
I forget to click reply all and only replied to you, so I resend the
email to the list....

2009/9/28 Ivan Herman <ivan@w3.org>:
> Bijan Parsia wrote:
>> Hope y'all don't mind my jumping in.
> :-)

You are ery welcome. I still fight the backlog of emails over the
weekend, but now we have internet at home! Finally!

> [skip]
>>> 1. What does it mean, in the case of RDFS, that a graph is
>>> inconsistent? I tried to find out how a _valid_ RDFS graph could be
>>> inconsistent... and I did not find it. Can you help in giving an
>>> example for what you were thinking about?
>> s p "<<"^^rdf:XMLLiteral.
>> This is inconsistent and pure RDFS (I believe a similar example is in
>> the ^^rdf semantics document). Obviously, additional datatypes can
>> introduce more ops for inconsistency, but xmlliteral is built in.
> Ah! I forgot about that one. I must admit that, in my mind, this was
> simply an invalid RDF file but that was wrong.

Actually, that is not enough. That is still consistent and the
interpretation must map "<<"rdf:XMLLiteral to some element that is not
an rdfs:Literal. For an inconsisitency you need additionally:
p rdfs:range rdf:XMLLiteral .

See, for example, at the end of the RDF Semantics spec:

An ill-typed literal does not in itself constitute an inconsistency,
but a graph which entails that an ill-typed literal has rdf:type
rdfs:Literal, or that an ill-typed XML literal has rdf:type
rdf:XMLLiteral, would be inconsistent. Another example from the spec
(http://www.w3.org/TR/rdf-mt/#RDFSINTERP) is:

<ex:a> rdfs:subClassOf rdfs:Literal .
<ex:b> rdfs:range <ex:a> .
<ex:c> rdfs:subPropertyOf <ex:b>.
<ex:d> <ex:c> "<"^^rdf:XMLLiteral .

> <editorial_comment>It is probably worth, in the final document, to make
> it clear for the reader that inconsistency in RDFS is related to
> datatypes and them only...</editorial_comment>

We can probably add a similar comment as they have in the RDF Semantic spec:
There is a characteristic signal of inconsistency which can be
recognized by the entailment rules, by the derivation of a triple of
the form
xxx rdf:type rdfs:Literal .
where xxx is allocated to an ill-typed XML literal by rule lg.

> That being said: this raised a further issue. Formally, D-entailement is
> separate from RDFS entailement. My understanding is that D-entailement
> is an addition to RDFS entailement (see [1]). To make it even more
> complicated, D-entailement is defined in terms of a generic terms of
> datatype maps, and the only datatype that is required to be part of such
> datatype map is XMLLiteral. XSD is just listed as an example.
> I wonder what we should say in our document. Do we mean D-entailement,
> in fact, or just RDFS entailement? (Stricly speaking, if it is RDFS but
> not D, then your example may not be considered as inconsistent...).

We say pretty clearly RDFS entailment and we mean it. Even under RDFS
you can have rdf:XMLLiteral inconsistencies. Under D-entailment you
can have further sources of inconsistencies depending on the datatype
map you use.

> My personal proposal would be to speak only of D-entailement to cover
> the XMLLiteral case (I think it would be really a micro level control to
> separate these two), but not to require XSD. Whether an RDFS entailement
> in a specific case covers XSD or not would be then part of a service
> description. Alternatively, we can require XSD for all RDFS entailement
> regimes...

I disagree. I would like to keep RDFS entailment. We could also add
D-entailement and talk about D-entailment assuming the XSD datatype

>>> 2. About those extra conditions that we have already discussed. The
>>> second one is taking care of the proliferation of blank nodes. That is
>>> clearly necessary and fine. However... for the 1st restriction
>>> referring to the subject position: isn't it only the rdf:_i properties
>>> that are the possible source of problems?
>> In general, yes.
>>> My impression is that only those properties, more exactly the relevant
>>> axiomatic triples, that are leading to an infinite number of triples.
>>> If so, isn't it simpler to refer, in that first condition, to the
>>> rdf:_i properties only, ie, restrict the axiomatic triples only to
>>> those rdf:_i-s that are in the graph.
>> Should work.

Should work, but I personally prefer a general condition. The second
source of infinite triples were those with literals in the subject
position, but those are rules out by requiring well-formedness, so we
could switch to just talking about rdf:_xxx in the condition.
> Great. I wonder whether it is not better to reformulate condition 1 to
> refer to that rather than the general condition on the variable being in
> subject. Something that says the axiomatic triples involving rdf:_i are
> taken into account only if rdf:_i is in the Graph. That would certainly
> make the rule clearer for the users and does not seem to change the
> outcome...
> Yes, I see your argument below...->
>>> (AFAIK, this is almost what Herman ter Horst does in his well known
>>> paper. More exactly, I think he allows for a bit more than what you
>>> describe: he takes the maximum 'n' for which an rdf:_n is in the
>>> Graph, and restricts the axiomatic triples to the rdf:_i i<=n cases.
>>> That could be a reasonable alternative, too, although generating some
>>> more triples than your restriction.)
>> Quite a few more perhaps a bit too easily. It depends on how many rouge
>> ^^rdf:_1000 there are.

Yes. It is an alternative. It would be good if somebody has an idea as
to how high the is in rdf:_i are in practise...

> :-) Yes, that is true. I am find restricting them to those that are
> really in use...
>> One could reasonably argue never to return a binding for which the only
>> justification is axiomatic. It would be, after all, trivial. Why clutter
>> up results that way?
>> (Does anyone need rdf:type to be returned for ?p rdf:type Property? It's
>> just one more thing to filter out.)
> -> this one:-) But I am not sure why restricting this. If I want to know
> all Properties in the graph, then why shouldn't I get them? If I do not
> query this, then it would not harm the result, would it?

- Show quoted text -

> Cheers
> Ivan
> [1] http://www.w3.org/TR/rdf-mt/#dtype_interp
> --
> 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

Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
United Kingdom
+44 (0)1865 283529
Received on Monday, 28 September 2009 13:06:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:57 UTC