Re: my action on conformance

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