Re: Reviewing Last Call RDFa

I'm sorry this is late.   I hope it is clear.

On 2008-06 -09, at 12:50, Ben Adida wrote:

>
> Tim,
>
> You sent comments to us a few weeks ago regarding RDFa:
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Mar/0297.html
>
> and I responded to most of them here:
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Mar/0299.html
>
> to which you responded here:
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Mar/0317.html
>
> I want to reiterate the points I made briefly, and complete the  
> response, just to be sure we have addressed this issue fully.
>
> Please let us know if these responses are satisfactory.

Short answer, no, they are not, they are reiterations, they do not fix  
the issues brought up.

>
>> ** Deployment path and architecture:
>> In general, is the deployment path for this spec that (a) it  
>> introduce  new attributes into the HTML namespace, and that  
>> conforming RDF-aware  HTML clients be expected in future to  
>> understand RDFa, or is it that  the GRDDL transform link from (b)  
>> the document or from (c) the HTML  schema?
>
> We are adding attributes to the XHTML1 namespace, and we expect RDFa- 
> aware clients to understand these as RDF.

Ah. You chose path (a). In that case you should not use (b) as it is a  
burden on the writer.  It also gives the reader the mistaken  
impression that RDFa can be understood just by implementing GRDDL.

> We will also be adding a GRDDL link in the XHTML namespace. We've  
> left the "SHOULD" on the @profile, because we've been told that a  
> number of GRDDL clients don't do namespace-based transformations (we  
> haven't confirmed this, we're just trying to be accommodating for  
> folks who want to choose this route.)

I think you are missing the point of the specification.  It is to  
ensure communication. It is to ensure that when both parties  
understand a given set of specs, then a precise set of triples is  
communicated between them.

Here is your argument rephrased:   It is true that some readers will  
not understand GRDDL, but that is OK as GRDDL is only a SHOULD.  Eh?   
The requirement is that ALL conforming clients understand ALL  
conforming servers.  If some clients understand GRDDL and some don't  
and some servers put the GRDDL profile in and some don't, then some  
client-server pairs will fail.

You could say, (1) "All servers MUST put the document GRDDL, and  
clients MAY use document GRDDL, or may use inherent knowledge of the  
spec." That would work in all cases.  But you don't want to as it is a  
pain for the server.

You could say, (2) "All servers MUST put the namespace GRDDL, and  
clients MAY use namespace GRDDL, or may use inherent knowledge of the  
spec." That would work in all cases.

You could say, (3) "All clients must have an inherent knowledge of the  
spec" and make GRDDL nothing to do with conformance, and that would  
work too.  But it would mean that a whole set of possible low-hanging  
implementations which are existing namespace-driven GRDDL  
implementations would not work, which would be a shame.

So I suspect you want go with (2).  To define RDFa conformance.   
Obviously, people might want to make documents in the short term which  
work equally well by conforming to the GRDDL spec (document profile  
method) and by RDFa but that is a distraction.




>
>
> The Follow-Your-Nose architecture principle is fulfilled by the  
> XHTML namespace document, which we are updating via the XHTML2 WG,  
> and the definition of XHTML1.1+RDFa. The GRDDL pointers are there  
> for convenience, but may be considered redundant.

Eh?  The GRDDL spec should define where a nose-following client looks  
for GRDDL pointers and where it doesn't.  Again, putting pointers  
places where they are not actually read is just confusing.  if the  
GRDDL spec is not clear on the algorithm, then it must be cleaned up.

Assuming (2) above is used, then the namespace document must have a  
pointer to the transform ina way that os followed by a conforming  
GRDDL client which knows nothing a priori about RDFa.

>
>> ** Purpose of the profile
>> Is the purpose of the profile to allow GRDDL engines to find RDFA,  
>> or  to protect against a non-RDFa document being interpreted as an  
>> RDFa  one, and that being taken as carrying more semantics than it  
>> actually  was intended to by its author?  From discussion with  
>> Ralph I  understand the position of this has changed since  I first  
>> looked at  RDFa.  I think it should be made clear how this should  
>> work.
>> I don't think "you can do whichever you want" is a suitable answer,  
>> as  the whole point is to have a set of standards which allow any  
>> client  and server (well, reader and writer)  to communicate.
>
> See above for the explanation.


Clearly I wasn't happy with that explanation above, and I don't see it  
addressing this concern.  This concern is, how do I know that an RDFa  
reader will not extract triples from a pre-RDFa HTML document that  
were not intended by the author?

>> ** DTDs
>> 4.1   "There SHOULD be a DOCTYPE declaration in the document prior  
>> to  the root element."  DTDs are a an obsolete technology. Suggest  
>> the  spec not refer to them in any way.
>
> You mentioned that the W3C is working on a DTD-free method of  
> validation. Hopefully that will be ready in time for RDFa 1.1. For  
> now, though, we have no choice but to refer to them in order to help  
> our users put a "valid according to W3C" logo on their pages.

This is completely backwards.  It is the tail wagging the dog.  The  
validator is a *service* provided to *support* the recommendations,  
not the other way around.   It is ridiculous to refuse to introduce  
new technology because it won't validate as old technology.  The  
validator should be fixed to follow new standards, and until it has  
been its output should be disregarded.

If we put together a new team to build a new validator, it would be  
useful of working groups involved could find volunteers to contribute  
to the team.  I know this has been a long-standing resource issue, but  
it is important.


>> 4.3  "A conforming RDFa Processor MAY make available additional   
>> triples that have been generated using rules not described here,  
>> but  these triples MUST NOT be made available in the [default  
>> graph]."
>> I feel this is an inherently weak method of specifying the meaning  
>> of  an RDFa document.
>
> We only mean this to enable RDFa processors to also process  
> microformats, if they so choose.

Ah I see.  "Default graph" -- the meaning of the document.  if someone  
makes some RDFb spec, can it not add more triples still?

> We felt that not leaving this door open might lead some folks to  
> interpret RDFa as ruling out an RDF interpretation for microformats,  
> which is not our intention.


good

> We could not find a cleaner way to phrase it without making the spec  
> much more complicated.

well, just writing that explanation helped me -- maybe it could go in  
the spec informationally.
>
> At the same time, we feel that the specification is quite strict and  
> thus strong about the [default graph], which is the whole enchilada  
> as far as RDFa is concerned.

Why "default"?  Are there options to change it?  Does it relate to  
SPARQL in some way (which has a concept of default graph)  i think the  
important thing is that the RDFa-derived graph is seen as being  
asserted by the document, but other things can also be. I think we  
agree on that.  I don't think the text in the spec conveyed it.

>
>
> -Ben

Received on Wednesday, 18 June 2008 12:55:15 UTC