[whatwg] [Moderator Action] Re: HTML5 ISSUE-120 rdfa-prefixes : Proposal to use RDFa according to spec
rubys at intertwingly.net
Fri Feb 4 06:54:10 PST 2011
On Fri, Feb 4, 2011 at 8:16 AM, Sebastian Heath
<sebastian.heath at gmail.com> wrote:
> I endorse Danny Ayers' proposal that HTML/HTML5 use RDFa as found in
> the RDFa specification .
> I particularly note that the user study and anecdotal evidence that
> are an important part of Ian Hickson's objections represent a very
> small sample. For my part, I find the flexibility and convenience
> offered by prefixes to be an essential factor in my choice to use the
> standard. Given that Ian's objections are so anecdotal, I'm confident
> that the personal perspective of end user's like myself will have
> equal effect in the conversation.
I encourage those that wish to contribute to actually join and participate.
To start with, any proposal needs to conform to the following and
actually be submitted to the working group:
If there are multiple irreconcilable proposals, this will likely
result in a survey. You can find plenty of examples of completed
change proposals and surveys in the right hand column of this page:
You can see examples of how surveys are evaluated:
- Sam Ruby
>  http://www.w3.org/TR/rdfa-syntax/
> On Fri, Feb 4, 2011 at 4:35 AM, Danny Ayers <danny.ayers at gmail.com> wrote:
>> Current Status [1,2] :
>>> We a single change proposal to simplify the HTML+RDFa specification
>>> by removing prefixes.
>>> - We have another change proposal to clarify how prefixes work and
>>> explain that they are optional.
>> I'd like to propose that HTML/HTML5 uses RDFa as found in the RDFa
>> specification . This includes the use of namespace prefixes.
>> I'll counter the argument for changing the spec in regards to
>> namespace prefixes given (by Hixie) on the WHATWG Wiki 
>> (statistical evidence is my trump card), and then also offer a
>> sub-proposal that may help alleviate the perceived problems (but isn't
>> tied to the main proposal).
>> The Change Proposal summary (regarding namespace prefixes) is:
>> Simplify the specification by removing features that are documented to
>> be confusing to users.
>> First, this change is unnecessary as the use of namespace prefixes is
>> optional (full URIs can be used inline instead). If this feature is
>> actually confusing to users then confusion may be avoided by only
>> providing guidance in the HTML documentation on the use of RDFa
>> without prefixes. If the facility coverage is adequate, then the user
>> won't have any need to consult the RDFa spec for the namespace
>> prefixes-based alternative.
>> Second, the arguments given in the Change Proposal that support for
>> namespace prefixes is confusing are mostly anecdotal - i.e. person A,
>> B and C say it's confusing. (Given the size of the Web, such material
>> isn't in short supply on any issue you wish to choose - given a little
>> time with a search engine, arguments that the British Queen is an
>> alien lizard can be amassed). Additionally no real distinction is made
>> between issues faced by end-user publishers and tool developers. This
>> is significant because the only time full knowledge of the namespace
>> prefix mechanism is essential is when developers wish to write a
>> parser - this seems something of a minority activity.
>> Statistical evidence  would suggest that in reality the existence
>> of the option to use namespace prefixes* isn't a barrier to widespread
>> deployment of RDFa: "The data shows that the usage of RDFa has
>> increased 510% between March, 2009 and October, 2010, from 0.6% of
>> webpages to 3.6% of webpages (or 430 million webpages in our sample of
>> 12 billion)".
>> (* It's possible that none of the pages analysed actually used
>> namespace prefixes, but that would still mean that their appearance in
>> the specs doesn't compromise the use of RDFa as-is)
>> A usability study is quoted, but as an internal Google study which was
>> flawed in design and limited in scope, I don't believe this can be
>> considered credible evidence.
>> (Personally my biggest issue there was that there were only 7
>> participants, but Hixie has assured me that conclusions can reasonably
>> be drawn from such small numbers of participants. On the blog it
>> states "people really don't have any problems dealing with URLs as
>> property names" - but as also stated there, this wasn't something that
>> the study was designed to test. A casual observation is not evidence.
>> There are also the issues mentioned in comments on the WHATWG blog 
>> : "Videos can’t be viewed out of Google. Bias on the part of the
>> creators of the study. Lack of outside involvement. No information
>> about where the people taking the study are employed. Lack of
>> diversity of demographics. Lack of proper, and neutral, oversight.
>> Interpretation by person or persons without proper background, and
>> neutrality. Single study, only.")
>> So onto a sub-proposal: a way of removing the need for the widespread
>> use of namespaces, and allow the use of short names rather than URIs
>> for common terms, would be to put such terms in the HTML namespace. In
>> other words, make a registry of terms along the same lines as already
>> used for common rel="" attributes. Of course such a registry could
>> never completely reflect the range of terms found in the wild, but it
>> does seem likely that in the near term at least, HTML developers are
>> most likely to predominantly use a limited range of terms, which could
>> be catered for in the HTML namespace.
>> This is akin to the approach taken by Google in their "Rich Snippets":
>> common terms are placed in a single namespace. As noted elsewhere, the
>> single-namespace approach is "hobbled"  and Google's particular
>> implemention is severely flawed  (the main flaw is
>> self-documenting, see http://rdf.data-vocabulary.org/name). But such
>> issues could be to some extent alleviated by providing references to
>> existing deployed vocabularies in the HTML namespace document, along
>> the lines of:
>> html:Person rdfs:subClassOf foaf:Person, vCard:Person, google:Person ...
>> (Probably done in RDFa)
>> Work would be needed in selecting suitable terms (the microformats
>> community could probably help there) and care taken in aligning them
>> appropriately with existing terms (i.e. where and in which direction
>> to use rdfs:subClassOf/rdfs:subPropertyOf,
>> owl:equivalentClass/owl:equivalentProperty etc).
>> Were this approach taken, I'd suggest it was used alongside including
>> RDFa as-is. As mentioned above, if the documentation guides the user
>> towards the syntactically simpler approach, any potential confusion
>> may be minimised.
>>  http://www.w3.org/html/wg/tracker/issues/120
>>  http://dev.w3.org/html5/status/issue-status.html#ISSUE-120
>>  http://www.w3.org/TR/rdfa-syntax/
>>  http://wiki.whatwg.org/wiki/Change_Proposal_for_ISSUE-120
>>  http://tripletalk.wordpress.com/2011/01/25/rdfa-deployment-across-the-web/
>>  http://blog.whatwg.org/usability-testing-html5
>>  http://blog.iandavis.com/2009/05/13/googles-rdfa-a-damp-squib/
>>  http://www.jenitennison.com/blog/node/104
More information about the whatwg