Re: Request to reopen ISSUE-120 rdfa-prefixes

Sam Ruby wrote:
> On 04/13/2011 01:46 PM, Nathan wrote:
>> Sam Ruby wrote:
>>> On 04/13/2011 10:46 AM, Henri Sivonen wrote:
>>>> On Tue, 2011-04-12 at 08:31 -0400, Sam Ruby wrote:
>>>>> On 04/09/2011 08:39 PM, Sam Ruby wrote:
>>>>>>
>>>>>> Additionally we would find the following to be "sufficiently novel":
>>>>>> multiple first hand statements from people who are implementing
>>>>>> distinct
>>>>>> large scale RDFa consuming tools on how they would prefer to proceed.
>>>>>
>>>>> While I have previously made the point that rehashing, re-questioning,
>>>>> re-clarifying, etc. "old information" is now off topic for this 
>>>>> mailing
>>>>> list; I want to now make it clear that any and all discussion
>>>>> (additional supporting evidence, rebuttals, requests for 
>>>>> clarification,
>>>>> etc) relating to "new information" are welcome here. I furthermore 
>>>>> wish
>>>>> to actively encouraged people aware of such new information to post it
>>>>> here in order to enable everybody to fully participate in the
>>>>> discussion.
>>>>>
>>>>> At the present time, I am aware of the following:
>>>>>
>>>>> http://krijnhoetmer.nl/irc-logs/whatwg/20110411#l-573
>>>>> http://lists.w3.org/Archives/Public/www-archive/2011Apr/0062.html
>>>>
>>>> The IRC log line you refer to contains a link to
>>>> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0126.html 
>>>>
>>>>
>>>>
>>>> Since my response to the objection poll on ISSUE-120 included the above
>>>> URL, a Chair considering it "new information" is rather odd. 
>>>> Frankly, it
>>>> makes me feel that my objection hasn't been processed properly. I'm
>>>> disappointed.
>>>
>>> I will agree that the quality of this item alone as "new information"
>>> is borderline at best; but we have indicated that we would be willing
>>> to evaluate it as a part of a larger package.
>>>
>>> I will further note that your objection was evaluated in the context
>>> of the only proposals which actually were brought forward:
>>>
>>> http://wiki.whatwg.org/wiki/Change_Proposal_for_ISSUE-120
>>> http://www.w3.org/html/wg/wiki/ChangeProposals/RDFaPrefixesNoChange
>>>
>>>> However, despite my disappointment, I'd be happy to see the Chairs
>>>> reconsider the ISSUE in the light of the "new" information of both a
>>>> Google engineer and a Facebook engineer expressing that their
>>>> implementations intentionally deviate from the RDFa spec in a way
>>>> relevant to the ISSUE.
>>>
>>> My suggestion to that those who are interested in pursuing this work
>>> is to close the gap between "intentionally deviate" and "actively
>>> support the specific change proposal that you put forward".
>>> Identifying a number of tools that "intentionally deviate" and do so
>>> in a consistent way would be borderline new information. Going further
>>> and identifying that they actively support something which nobody
>>> fleshed out and actively proposed previously... that would be a much
>>> easier case to make.
>>
>> Indeed, and for the time being it seems clear to me (at least) that this
>> is a simple case of following the robustness principle / Postel's Law:
>>
>> Be conservative in what you send; be liberal in what you accept.
>>
>> Do they advise to send the prefix declaration, yes, do they require it
>> when consuming, no. The likes of Facebook/Opengraph are only concerned
>> with consuming their own og:/fb: data at the moment, if or when a time
>> comes that they wish to consider other RDFa data too, then the prefix
>> declarations will become far more important to their consuming software.
> 
> I read this as "respect the prefix declaration if present, otherwise 
> recover in a predictable manner".  For now, I will simply note that this 
> is slightly different than what James originally outlined[1]:
> 
>> Tools processing RDFa in HTML MUST NOT use any in-document mechanism
>> to bind prefixes to URIs, but instead MUST only recognise prefixes as
>> they are registered
> 
> Either or both approaches can be proposed should this issue be reopened, 
> but I will encourage people to work together to converge on as few 
> proposals as is practical, and for any such proposal be consistent with 
> the new information that is provided.
> 
> In short, is there any evidence that there is "a path by which reality 
> can be made to match"[2] what James outlined?  I.e., is this something 
> that tool builder would be willing to do?  Or would they prefer what 
> Nathan has outlined above?

Probably worth noting that RDFa already includes support for default 
profiles to address exactly this situation. Each default profile is 
managed by W3C and includes a to-be-determined list of prefixes, so for 
example if og: and fb: were in the profile, then any user who forgot to 
include the prefix declarations would still be covered by the default 
profile (implemented by the RDFa processor).

This is the inverse of what James proposes and instead is, use what the 
author has provided, but here's a list of the common ones people may 
have forgotten. RDFa processors can also include rich lists of popular 
prefixes if they wish [*].

So, ultimately in the RDFa WG we've already covered as much as we 
possibly can to handle edge cases and provide recovery methods so that 
people can be liberal in what they accept. However we did find that 
prefixes were needed and found to be useful. Thus, RDFa already covers 
these cases, and it allows people to author RDFa without prefixes if 
they so desire. It does not however ban a feature which people who use 
"URIs as names" have found most useful for over a decade, unlike that 
which James outlines.

[*] Probably worth noting that RDFa is RDF in Attributes, and that most 
consumers are part of RDF libraries which heavily use prefix methods in 
all serializations and contributing specs like query languages, and 
often come with rich prefix recognition lists, indeed we even have 
websites which return lists of popular prefixes. Did anybody stop to ask 
the RDF and Semantic Web communities why they still use prefixes 
everywhere and haven't thought to remove them? The answer would be 
because if there was such a wiki-register, then you'd conceivably need 
one per domain name or datasource - at the last count there was 
21,151,452,895 triples covering 2,129,934,348 distinct subjects, if even 
0.0001% of those are from ontologies (thus needing a prefix) then that 
still a far bigger than a wiki could ever manage amount of prefixes, and 
far more than you could ever expect users to remember and not collide 
with. Prefixes are an author aid, and reduce bandwidth over the wire, 
they are not stable registered names for a small number of ontologies, 
even though some of them are used pretty reliably by the community.

Best,

Nathan

Received on Wednesday, 13 April 2011 18:42:00 UTC