Re: my action on conformance

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


-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Monday, 24 September 2007 13:42:41 UTC