- From: Ivan Herman <ivan@w3.org>
- Date: Mon, 24 Sep 2007 15:58:30 +0200
- To: Mark Birbeck <mark.birbeck@formsPlayer.com>
- CC: Niklas Lindström <lindstream@gmail.com>, RDFa <public-rdf-in-xhtml-tf@w3.org>
- Message-ID: <46F7C286.4010505@w3.org>
That is the effect when catching up with mails... one answers the ones as they come in the listing and sees the other mails later:-( I have begun looking at the syntax document again, but the bulk of that will be for tomorrow (or later:-) ivan Mark Birbeck wrote: > Hi Ivan, > > Thanks for the comments, although they would now be best directed > towards the syntax document. > > The core of my suggestion was to use the _idea_ of separate graphs; I > really don't care whether we use the exact term 'named graphs' or not, > but by introducing the _concept_ of distinct graphs, I'm pretty > confident I've found a way to provide both a clear conformance > definition, as well as provide some scope for parser extensions. > > To recap the context for all of this, although Ben generously conceded > to the view that we should not prevent a parser from generating > 'extra' triples, I realised that I had only been looking at the issue > from that standpoint, and I hadn't considered the question from the > angle that most concerned Ben, which was that a parser could claim > conformance based on generating just about anything! :) > > By saying that there is _at least_ one graph generated that must > exactly match the criteria in the spec, we are able to address Ben's > concerns; and by saying that a processor is free to generate > additional graphs we provide freedom for the kinds of use-cases I'm > talking about. > > So the latest draft of the syntax document, as issued for review last > Friday, has wording that attempts to have the best of both worlds. It > simply says that triples defined by the spec should go into a 'default > graph', and that whilst a processor is free to generate 'extra' > triples, they should not be placed into this default graph. The term > 'named graph' is not used, although any reader familiar with RDF and > SPARQL will of course see that they can use named graphs as an easy > way to implement this. > > Note also that anyone implementing an RDF parser with no extensions > will not need to do anything here; if there are no extra triples, then > there need be no extra graphs, and the implementer only needs to > generate one graph. (SPARQL defaults to querying the default graph if > no name is given in the query, so nothing changes there.) > > Obviously this is still open to discussion and refinement, but the > debate should now focus on the prose in the syntax document. > > Best regards, > > Mark > > On 24/09/2007, Ivan Herman <ivan@w3.org> wrote: >> Mark, >> >> I know that named graphs appear, in some way, in the SPARQL spec, but >> the concept does not have a general acceptance and exact semantics in >> terms of W3C documents. I am sorry if I sound pedantic here, but I do >> not think we should issue a W3C recommendation referring to a >> non-finalized feature like named graphs. >> >> Ivan >> >> Mark Birbeck wrote: >>> Hi Niklas, >>> >>> That's a good idea, but I'm not sure it addresses the issue >>> completely. The problem I'm thinking of concerns RDFa *consumers* who >>> want to get as many triples out of a document as possible in order to >>> do something clever with them, and may choose to do things like >>> generate a triple for each image or anchor tag. In this situation it >>> really doesn't matter what an author has put in their document, since >>> the processor will do pretty much what it wants. >>> >>> However...I think I have a solution which gives Ben the security that >>> he wants, makes conformance much easier to define, and still allows >>> parsers to add extra triples if it wants to. >>> >>> What we do is use the concept of 'named graphs'. >>> >>> All we have to do is to say that an RDFa parser MUST generate one >>> named graph (or rather a 'default graph') that EXACTLY matches the >>> triples we would expect--no more, no less. But then we can also say >>> that an RDFa parser MAY generate further named graphs, as it likes. >>> And we further say that if that parser generates triples that are not >>> justified by the specification, then it MUST NOT put them into the >>> default graph. >>> >>> This means that our test suite would change back (sorry Michael!) to >>> being a simple check for 'these triples and no more' in the default >>> graph, rather than the current tests which use the idea of 'at least >>> these triples'. This makes the conformance tests we were talking about >>> extremely easy, and it also gives Ben the security he was looking >>> for--that no parser can claim conformance if it 'pollutes' the default >>> graph with weird triples. >>> >>> But the interesting thing is that this also means that even if the >>> spec changes in the future, the additional interpretations of nodes >>> that a parser chose to add will be completely separate from any new >>> triples. >>> >>> For example, say that I decide in my parser to create a triple for >>> each <img> tag, and I use 'foaf:Image' as the mapping. But let's also >>> imagine that in the future XHTML+RDFa 1.1 also adds a representation >>> for <img>, but we decide that DCMI is a more appropriate mapping. With >>> the named graph approach there is no problem, since my parser's >>> additional triples were never allowed to be in the default graph >>> anyway, so they can happily co-exist with the new triples which _will_ >>> be in the default graph. >>> >>> Just in case anyone thinks this is complicated, note that for most >>> parsers nothing will actually change here. If all a parser does is to >>> generate the triples that are defined in the spec, then it simply >>> continues to do that, remaining fully conformant. However, parsers >>> like mine that generate 'extra' triples must now move them into a >>> separate graph, so that the default graph only contains the exact >>> triples that are defined in the spec. >>> >>> Everything I've defined here can be achieved with just a few extra >>> lines in the spec, I believe. >>> >>> Regards, >>> >>> Mark >>> >>> On 20/09/2007, Niklas Lindström <lindstream@gmail.com> wrote: >>>> .. Missed "reply to all"; sorry Mark; sorry all. I wrote: >>>> >>>> >>>> Ben, Mark, >>>> >>>> I think you're both correct here. :) >>>> >>>> A thought -- how about using @profile for this? Meaning that: if the >>>> value of @profile in an XHTML document is "http://www.w3.org/ns/rdfa/" >>>> *and nothing more*, an RDFa parser should not output anything more >>>> than what is defined in the XHTML1.1+RDFa spec? >>>> >>>> If it is not present, or contains multiple profile references, the >>>> situation is less clear (even indeterminate?) and thus this >>>> requirement isn't imposed. >>>> >>>> Best regards, >>>> Niklas >>>> >>>> >>>> On 9/20/07, Mark Birbeck <mark.birbeck@formsplayer.com> wrote: >>>>> Hi Ben, >>>>> >>>>> I have to admit though, that I hadn't really thought about it from the >>>>> direction you are coming from. >>>>> >>>>> What I was trying to achieve was that if some parser decides to >>>>> generate 'local' triples that are for its own use, or a developer >>>>> wants to add 'experimental' triples whilst trying out new features, we >>>>> shouldn't necessarily say that this parser is non-conformant--provided >>>>> that it generates at least the minimum triples. >>>>> >>>>> However, the issue you raise is slightly different, and I think we >>>>> should try to take it into account. >>>>> >>>>> An example came up the other day, when I was showing a friend how the >>>>> RDFa parser worked, and I showed the mark-up to illustrate how easy it >>>>> was to refer to a book with @instanceof and @resource. His immediate >>>>> question was to ask how this mark-up related to the use of @cite, and >>>>> of course _my_ response was to say that it would be easy to add the >>>>> use of @cite to the RDFa parser. >>>>> >>>>> But the I realised that were I to do that, it could become a problem >>>>> in the future if the taskforce issued an XHTML+RDFa 1.1 that included >>>>> @cite, and it was done in a way that was different to the additional >>>>> feature I had added to my parser. >>>>> >>>>> So I think we should allow the 'extra triples'--I think we definitely >>>>> need that--but perhaps we should also indicate somewhere that >>>>> generating extra triples from XHTML itself might cause you problems in >>>>> the future, since XHTML+RDFa may define further rules. >>>>> >>>>> Any thoughts on that? >>>>> >>>>> Regards, >>>>> >>>>> Mark >>>>> >>>>> >>>>> On 20/09/2007, Ben Adida <ben@adida.net> wrote: >>>>>> Hi all, >>>>>> >>>>>> I have an action to look into conformance and "extra triples" >>>>>> >>>>>> [NEW] ACTION: Ben research whether "Can an RDF-conformant parser >>>>>> generate additional triples than those specified in the Syntax >>>>>> specification?" is an already closed issue [recorded in >>>>>> http://www.w3.org/2007/09/14-rdfa-minutes.html#action12] >>>>>> >>>>>> >>>>>> My worry was that parser libraries that generate random "dirty triples" >>>>>> would still be compliant and potentially create a problem for people who >>>>>> use them. >>>>>> >>>>>> Apparently, I'm the only person worried about this (blame it on my >>>>>> security paranoia), so I'll happily withdraw my objection here and say >>>>>> that I'm happy with the current SPARQL-based test cases and the >>>>>> corresponding "presence of triples" compliance approach. >>>>>> >>>>>> Note that this does *not* mean that RDFa will generate triples for the >>>>>> old Dublin Core notation, just that if a tool like Mark's Sidewinder >>>>>> chooses to generate triples for the legacy Dublin Core approach, we >>>>>> won't say that it no longer complies with RDFa. >>>>>> >>>>>> >>>>>> -Ben >>>>>> >>>>>> >>>>> -- >>>>> Mark Birbeck, formsPlayer >>>>> >>>>> mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232 >>>>> http://www.formsPlayer.com | http://internet-apps.blogspot.com >>>>> >>>>> standards. innovation. >>>>> >>>>> >>> >> -- >> >> Ivan Herman, W3C Semantic Web Activity Lead >> Home: http://www.w3.org/People/Ivan/ >> 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/ PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Monday, 24 September 2007 13:58:20 UTC