Re: my action on conformance

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


-- 
  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 Thursday, 20 September 2007 10:26:52 UTC