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

Bijan Parsia wrote:
> Hope y'all don't mind my jumping in.
> 

:-)

[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.

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

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

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...

>> 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.

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, 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?

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