Re: my action on conformance

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