- From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
- Date: Mon, 28 Sep 2009 14:06:16 +0100
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
Ivan, I forget to click reply all and only replied to you, so I resend the email to the list.... Birte 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: http://www.w3.org/TR/rdf-mt/#RDFSINTERP 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 map. >>> 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? Cheers, Birte - 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 Oxford OX1 3QD United Kingdom +44 (0)1865 283529
Received on Monday, 28 September 2009 13:06:59 UTC