W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > July 2008

Re: Late, but I have reservations.

From: Ben Adida <ben@adida.net>
Date: Fri, 25 Jul 2008 16:15:05 -0700
Message-ID: <488A5E79.2030102@adida.net>
To: gannon_dick@yahoo.com
CC: public-rdf-in-xhtml-tf@w3.org


Your comments are confused. I'll try once more to point you in the right 
direction, but at some point we may have to simply agree to disagree.

> DC uses "object notation", e.g. dc.title rather than dc:title,

Let's be specific, the current recommendation for Dublin Core expressed 
in HTML uses dc.title. And you can keep on doing that. Or you can use 
RDFa if you need other vocabularies, too. Or you can use both, and they 
won't interfere with one another. I don't see any incompatibility there, 
only a different architecture choice.

> GRDDL uses this (carefully - generic does not mean without rules) to
> get name-space bindings.

That's incorrect. GRDDL does whatever you tell it to. Of course, there 
is *a* GRDDL transform that parses the "dc.title" notation, just like 
there is *a* GRDDL transform that parses RDFa [1].

> It would surprise me if the DC was considering the use of the attributes added with RDFa.  They simply
> don't need them.

Well, no need to speculate, neither one of us knows what DC will choose 
to do here. The Dublin Core community has been kept informed of our 
progress and has provided informal reviews, and so far no complaints. If 
you know of specific complaints, do let us know.

> Toby's example: <title property="dc:title" ...>
> could as easily be a #FIXED attribute in a DTD - it is always true.
> <title instanceof="dc:subject" ... might be a bit more interesting,
> but still there are ways to do this that computers already understand
> very well.

What are these existing technologies you refer to? DC's recommendation 
is about Dublin Core only. GRDDL is a generic transform-based technology 
that doesn't specify an actual syntax. eRDF is pretty close, but isn't 
able to express as much structured data as we wanted as modularly as we 
wanted. There were no generic ways to include RDF in HTML that fit our 
requirements, thus we came up with RDFa.

>  <link rel="stylesheet" and <link rel="alternative" ...
> talk to your browser, not your friends.

RDFa also talks to your browser. I'm as big a geek as the next guy, but 
I prefer to read rendered HTML, and let my browser read RDFa so it can 
help me connect information, etc... The actual RDFa attributes are, of 
course, meant for machines, just like <link rel="alternate">. Only with 
RDFa, I get a closer link between the human and machine readable.

>> Less clarity for whom? There exist plenty of mechanisms for 
>> expressing human-invisible metadata already. <link rel="alternate">
>> is one of them. Or simply publishing RDF/XML.
> Variety in modes of communication is wasted on computers (<head>),
> but beloved by humans (<body>).

I don't understand what you mean. Can you be more specific and focused 
on what you think the problem with RDFa specifically is?

> So, the gun wasn't smoking when you sold it?

That's quite a baffling statement.

On the one hand, you're claiming that there are plenty of existing tools 
that do what RDFa does, so why do we need it.

On the other hand, you're claiming that we've created a technology with 
new and dire privacy consequences akin to a weapon.

Those two statements cannot both be true. Either RDFa is redundant or 
it's new and harmful (or it's new and harmless, which of course is what 
we believe.)

Specifically, you don't seem to take issue with GRDDL and Dublin Core, 
which are all about machine-readable data. I don't see what privacy 
violations are enabled by RDFa that aren't already enabled by the 
technologies you prefer.

 > Anyone who caches your
> personal information forever is not your friend. Although you can't
> easily stop them, you can't "vision statement" away the problem
> either.  An RDF inference engine with access to years of your
> writings needs an IGNORE command of some sort.

Can you be more specific as to what kind of privacy violations/threats 
you believe RDFa enables? Your PDF was not helpful, because none of it 
was specific to RDFa. It was more a criticism of structured data in 
general. Please provide a specific example of a privacy-invading 
scenario and how RDFa specifically contributes to it, so we can get a 
better handle on what worries you.


[1] http://ns.inria.fr/grddl/rdfa/
Received on Friday, 25 July 2008 23:15:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:28 UTC