Re: Review of Best Practice Recipes for Publishing RDF Vocabularies

Hi Ralph, Ed, please read my comments inline:

Ed Summers escribió:
>>>> ... and the onus should be on semantic web clients to send
>>>> the appropriate accept headers, rather than covering up for the sins
>>>> of IE.
>>>>         
>> I do, however, agree with this point.  If there were an IE-specific
>> user agent string I'd be inclined to continue showing vocabulary
>> publishers how to take advantage of it.  The broad-brush
>> ^Mozilla/ pattern is indeed painful for many clients.
>>
>>     
>>>> If we plan on keeping the ie/hack rule i think we should discuss it a
>>>> bit more in the text of the recipes document--providing the accept
>>>> headers that ie sends, and demonstrating why they are problematic.
>>>>         
>> Or describe why our conditional rewrites aren't sufficient to
>> fully implement the HTTP spec.
>>     
>
> I don't understand completely. I only wanted to point out that if
> these recipes are followed, a developer who changes their browser
> accept headers to prefer application/rdf+xml when it is available,
> will never get it. This seems unfortunate to me, but perhaps it's
> enough of a corner case to not matter that much?
>   
Unfortunately, I think this issue is serious. For instance, I wonder
whether it may cause problems with semantic web browsers embedded into
Firefox (i.e.: Tabulator).

By the way, one of my proposals for ISSUE 44 [1] might be useful to
partially solve this issue too.

>>> You are raising at least two different issues here:
>>>
>>> 1) Do we really want to serve RDF as the default response? From my point
>>> of view, if the client doesn't send an "Accept" header, any
>>> representation is equally valid.
>>>       
>> yep.  So we chose the representation that wouldn't break
>> older SemWeb apps.
>>
>>     
>>> The suggestion to use RDF as the
>>> default response reflects the implicit assumption that the vocabularies
>>> are published mainly for their consumption by automatic agents.
>>>       
>> I'm not sure I'd agree with that.  At least, I wouldn't want to use it
>> as a justification for future actions.  With the current recipes and
>> with GRDDL and RDFa we're trying to accommodate both humans
>> and machines.
>>     
I think we are in sync here, Ralph. It is just that I failed to explain
my point.

When I said that, what I had in mind was that the previous editors give
more priority to avoid breaking existing semantic web agents over doing
so to user agents (web browsers). For them, it is more important to
serve RDF to a semantic web agent that doesn't send the 'Accept' header
than to serve HTML to a web browser that doesn't send the 'Accept'
header (or sends an strange value). (The exception, of course, is IE)

In other words: if the default response is RDF, we break those web
browsers which don't set a proper value for 'Accept'. On the other hand,
if the default response is HTML, we break those semantic web agents
which don't set a proper value for 'Accept'. The fact that the Recipes
document suggests to serve RDF by default indicate that the former is
preferred.

>>>> Appendix B
>>>>
>>>> Isn't it more appropriate to cite RFC 3896 instead of XML-NS for the
>>>> syntax of fragment identifiers?
>>>>
>>>>         
>>> (I assume you mean RFC 3986 instead of RFC 3896).
>>>
>>> Good catch! Actually, I think that any reference to the XML-NS
>>> Recommendation should be removed from the Recipes. We are dealing with
>>> URIs, not with XML namespaces.
>>>       
>> I disagree.  We're talking about RDF/XML here, not fragments
>> in general.   For better or worse, RDF Class and Property names
>> are currently restricted to NCNames.
>>
>> http://www.w3.org/TR/rdf-syntax-grammar/#rdf-id
>>     
I'm not completely convinced :-) I admit I'm not aware of the fine
details of the RDF/XML syntax, so you can probably help me to better
understand this question. As you said, the rdf-id production applies to
the rdf:ID attribute in the RDF/XML syntax. However, the rdf:about
attribute can be used as well, and its value must follow the
URI-reference production [2], which (I understand) is not restricted to
a NCName. Probably I'm missing something obvious, so I would be very
grateful if you could expand on this.

Best regards,

[1] http://lists.w3.org/Archives/Public/public-swd-wg/2007Aug/0008.html
[2] http://www.w3.org/TR/rdf-syntax-grammar/#aboutAttr

-- 
Diego Berrueta
R&D Department  -  CTIC Foundation
E-mail: diego.berrueta@fundacionctic.org
Phone: +34 984 29 12 12
Parque Cientifico Tecnologico Gijon-Asturias-Spain
http://www.fundacionctic.org

Received on Saturday, 19 January 2008 00:12:56 UTC