Re: Working Group Decision on ISSUE-120 rdfa-prefixes

A few quick comments here, as one who works with RDFa regularly for
organizations such as the Library of Congress.

1) One of the principle reasons for prefixes in the first place is to
differentiate between two distinct ontologies that may be coexistent in HTML
content. Given the looser version of RDFa within HTML, the hope that such
prefixes can be associated with specific namespaces is probably unrealistic,
though there was some significant work that Liam Quinn did with regard to
RDFa and namespaces that i believe was floated around August of 2009 that
should be referred to there as potential alternatives for binding such
prefixes to their associated namespaces inline within an HTML "no
namespaces" context. However, the use case still stands, and if anything is
becoming more signficant within the corpus of RDFa enabled content ...
especially in those situations such as Drupal where there is a distinct
correlation between RDFa and binding of terms across multiple categories
(which is just another flavor of namespace).
2) Google produces RDFa output in a number of different contexts, and in
general does it right. This is also true of Wikipedia (and its associated
Freebase and DBPedia systems) and a number of news organizations, of which
the New York Times and Reuters are both useful examples.  Basing
standardization of RDFa usage on one platform (Facebook) seems to be a
questionable precedent to use, even if it reflects the CURRENTLY largest
provider. There are indications that RDFa interest is growing dramatically
among larger commercial content providers, which usually also indicates that
the number of organizations that ARE using RDFa correctly are also likely to
be growing.
3) I would advocate that the HTML Working Group consider the possibility of
establishing a white list of standardized RDF prefixes that will be
interpreted properly by browsers even in the absence of binding URIs, and
that some mechanism also be established that would provide a way to identify
new prefixes for formal identification when the prefixes are not in this
white list ( I know, proposing that mechanism would be preferable, and I
hope to do so at some point soon).
4) I would contend that now, and for the foreseeable future, most RDFa will
NOT in fact be generated by hand coding, but instead will be generated via
some formal generative algorithm or user interface mechanism. The amount of
hand coding of HTML will likely be far smaller (perhaps by several orders of
magnitude) to the RDFa assertions introduced by document enrichment programs
in particular. As such, any purported complexity of RDFa will mostly likely
fall not upon the naive HTML coder but upon the developer of these
algorithms, who likely will have a far higher incentive to get it right -
Facebook not withstanding.
RDF by itself is far from trivial in its conceptual complexities - but the
benefits of embedding RDFa within content usually makes it worthwhile for
several classes of institutional developers - government entities such as
the Library of Congress, news and information providers such as the New York
Times (which has been doing RDFa with great results for several years),
reference entities such as Wikipedia and so forth, as well as internal
corporate systems that make use of HTML-centered document management
systems. In most of these cases, such RDFa assertions become critical for
both determining relevant content used by external systems and provide means
to activate linkages automatically to other points in the system where it is
no longer feasible to maintain such linkages manually.

Kurt Cagle
Information Architect
Avalon Consulting
c <kurt.cagle@gmail.com>aglek@avalonconsult.com
443-837-8725



On Thu, Apr 7, 2011 at 3:55 PM, Sam Ruby <rubys@intertwingly.net> wrote:

> On 04/07/2011 11:59 AM, Tab Atkins Jr. wrote:
>
>> On Thu, Apr 7, 2011 at 5:34 AM, Sam Ruby<rubys@intertwingly.net>  wrote:
>>
>>> Operationally, there is little difference between quickly responding --
>>> even
>>> to reasonable inquiries -- and ongoing discussion.  Additionally, I would
>>> rather not discuss decisions that already are the subject of a Formal
>>> Objection.
>>>
>>
>> Note that jgraham's new information and intended action regarding a
>> new change proposal are both directly relevant to my objection; it was
>> precisely the discarding of similar information that caused me to
>> raise the objection in the first place.
>>
>
> Thanks.
>
> It is my expectation that the chairs will not come to a consensus on
> James's request[1][2] until midweek next week at the earliest given our
> other priorities.
>
> Just as a heads up, should this issue ultimately get reopened, I will
> likely follow up with a request that you voluntarily withdraw your formal
> objection, just like I did for issue-30:
>
> http://lists.w3.org/Archives/Public/www-archive/2011Mar/0004.html
>
>  ~TJ
>>
>
> - Sam Ruby
>
> [1] http://lists.w3.org/Archives/Public/public-html/2011Apr/0153.html
> [2] http://lists.w3.org/Archives/Public/public-html/2011Apr/0154.html
>
>