Re: [RDFa] ISSUE-28: following your nose to the RDFa specification

Hi Dan,

I agree with Ben's comments in reply to this post, but would like to
add some more.

On 21/06/07, Dan Connolly <connolly@w3.org> wrote:
>
> On Thu, 2007-06-21 at 10:47 +0100, Mark Birbeck wrote:
> > Hi Dan,
> >
> > Since RDFa could be processed server-side by pipeline tools, and
> > client-side by an assortment of parsers, then I think it's legitimate
> > to have different ways that RDFa might be spotted. My interpretation
> > of the proposal under discussion is that it would give us the
> > following scenarios:
> >
> > No DTD and no profile: it's legitimate to run an RDFa parser over an
> > HTML/XHTML document, but you might not find anything.
>
> This issue is about the case where you do find an RDFa
> attribute (about/resource/etc); how do
> you know that the author meant it in the RDFa sense?

You don't. But I'm sure you'll agree that the chances of false
positives are *enormously* smaller than the situation with
microformats. To get a false positive with a microformat you only need
to find a value in the much-used class attribute that matches one of
the many possible values in the various microformat 'taxonomies'. And
as each new microformat is added, the chances of false positives
increases.

With RDFa, to get a microformat, you'd need authors to actually add
attributes to their mark-up that are not currently found in HTML or
XHTML. So you'd need an author to add one or more of @about, @content,
@datatype, or @property. I've not come across anyone doing this so
far, and believe it to be very unlikely. I'm not ruling it out, I'm
just saying that given the way most HTML/XHTML authors currently work,
it is an order of magnitude less likely than overloading @class
values. And as RDFa becomes more well known, the chances of such false
positives *decrease*. (Since it's less likely that someone devising
their own language based on HTML would re-use these attributes.)


> >  At worse you
> > might find things like <a rel="license" ... >, etc., which are already
> > defined by HTML/XHTML.
>
> No, at worse you get some triples out that the author didn't intend
> because s/he didn't mean the markup to have RDFa meaning.

@rel and @rev is a different example. As far as I am concerned, given
the HTML 4.01 definition I can safely parse *any* document currently
on the web, and interpret @rel and @rev as a predicate which expresses
a relationship between the current document and the value expressed in
@href. Whether the author intended triples or not, doesn't matter; it
may not have occurred to me that my documents would be spoken to a
blind user, but that doesn't make it wrong for a voice browser to
process and 'interpret' my documents in a different way. So too with
an RDFa parser.


> With no DTD and no profile, you can run an RDFa parser, but
> I don't see how you can legitimately hold the author
> to the triples you get out.

I'm intrigued to know what you mean by 'hold the author to'. This
isn't a concept I've come across in RDF in a sense that is independent
of some other 'meta level' dealing with trust relationships. My
reading of RDF is in fact the opposite; since "anyone can say anything
about anything", I am perfectly entitled to generate any triples I
like from your documents.

However, RDFa has not simply been plucked from the sky to give any
interpretation we like; with RDFa we've taken a path of trying to
generate the triples that seem most logical, based on a combination of
making explicit the semantic features already contained in HTML (such
as @rel, @rev, <meta> and <link>), and then in addition, carefully
adding a small number of new attributes that have a clear meaning, and
do not conflict with any other attributes in use in current mark-up.

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Saturday, 30 June 2007 19:49:24 UTC