- From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
- Date: Mon, 28 Sep 2009 14:16:13 +0100
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
2009/9/28 Ivan Herman <ivan@w3.org>: > Hi Birte, > > Birte Glimm wrote: [snip] >>> <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. > > Something like that. This is only an informative comment, so we can > wordsmith later (the text you have may be a little bit too theoretical > for a lambda reader, but tastes differ...) I'll add some (hopefully) more accessible text to the document. [snip] >>> 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. > > O.k., that can also work. It means yet another category, distinct from > RDFS, OWL, etc. I do not really have strong feelings about that. Maybe I was too quick. I would like to agree on RDFS first. We can then see what else we need for D-entailment (if anything) and if it turns out to be easy, we can cover everything under D-entailment and just state what is different for RDF(S). My main arguement here is, let's get RDFS right first and agree on that. >>>>> 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. > > So this falls under the question whether we try to be future proof with > regard to the literal-in-subject restriction... Well, I am not dead > against this, but this should be made very clear that this is a choice > we make. If we decide to keep to today's RDF, then rdf:_xxx is simpler > for the lambda user to understand... Yes. the more general condition is more future proof and does no harm other than that it is slightly less straight forward to understand for users. I'll add a comment to explain the choice and we can keep this as something that we might want to change (to rdf:_1, ... only). >>> 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... > > Well, in a 'correct' usage these are rdf:Seq entries, so the question is > how large such containers are. The trouble, of course, is that there is > no requirement that people would not use any rdf:_i, ie, start a Seq by, > say, rdf:_10000000000000000 and go from there:-( > > Ie, Bijan is probably right and we should not go there... I would also prefer not to go there. Then I would prefer the restriction that you have to give limits for queries that match the axiomatic triples, but my favourite solution is what we have now. Birte > Cheers > > Ivan > > >>> :-) 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 >> >>> 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 >>> >> >> >> > > -- > > 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:16:48 UTC