Re: GRDDL profile for RDF-A

Elias Torres wrote:

Hi,
>
> In short, I don't think profile urls work because not everyone uses them
> (point in case microformats). 
This is a similar rationale to what appears to be HTML 5's decision to 
drop the @profile. I'm thoroughly unconvinced by it. A profile, or lack 
of one, doesn't stop a consumer from trying to parse the page for RDFa 
or microformats, or eRDF or anything else, but the presence of one does 
let an author state unambiguously how their document can be interpreted. 
Some consumers may want to take a liberal attitude, and have a stab at 
anything it comes across, but others will not want to bother unless they 
are sure the page contains RDFa.

For example, I've got a grease monkey script that lets me know if the 
page I'm on contains eRDF. It just looks for the profile, because I 
don't want the performance lag of looking for other indicators that eRDF 
is being used, and in this situation, I'd rather err on the side of 
performance and chance missing some eRDF without a @profile, than  slow 
down the browser (and possibly be bothered by false positives). I can't 
do that with RDFa if there's no way of indicating that the page contains 
RDFa or not - so I have to run it all through the RDFa parser and see 
what comes out?
> Therefore, to depend on it to find RDFa
> would be misguided. There are other practical issues, such as limited
> access authors/publishers that don't have control over the head section
> of the page. 
Again, offering a profile for authors to use doesn't prevent users of 
CMSs etc from writing RDFa - it just lets  those who /do/ have control 
use it to be unambiguous about what they mean.
I think it's unnecessary to be shutting down options at the moment, 
especially given that adoption of data-in-html techniques is only just 
beginning to gain ground with mainstream authors and developers.

CMS's will adapt if there is demand, and other methods for flagging RDFa 
content outside of the head could be offered - perhaps something like  
*[@rel="profile"] would not be too horrible a workaround?
> This violates one of our principles of copy and paste/drag
> and drop. It would require copying the profile and enabling on the page
> you pasted it, hence making it more cumbersome that copy and paste alone.
>
>   
Copying and pasting is an activity that involves a human looking at the 
data before and after the operation, and will be able to spot if 
something is amiss, so the presence or absence of a @profile is not 
important here.

But for other applications, where machines have to interpret without 
human guidance, a @profile could be very useful indeed.
> We want metadata to be first class in (X)HTML and not depend on special
> codes to tell us if there's metadata.
HTML (I'd argue) isn't really suited for being a candidate for treating 
data as a first class citizen, because its primary use is for presenting 
documents (not units of data) to humans. And when you create a 
human-readable document (like a web page) from machine readable data, 
you generally have to do some formatting to make it palatable to the 
humans.  And if you want to provide a machine readable version of human 
readable information, you have to  somehow embed that  machine readable 
data in your html in a way that won't frighten the humans. There's a 
slight mismatch here, illustrated by the accessibility problems caused 
by microformats' abbr[@title] pattern.  Perhaps XHTML 2's @content will 
help make this cleaner, I don't know (I've not been able to find out 
what screenreaders etc are supposed to do with it), but it doesn't solve 
it entirely; you still have to provide the information twice, and you 
can't, for instance, stuff XML fragments into an attribute.

HTML data formats are a useful technique, but they are inevitably a 
compromise.

I think the heart of my disagreement with this attitude towards 
@profile, is that you obviously want *RDFa* to be in First Class, and 
all *other* methods of embedding data in html to lump it in Third - 
which is pretty much the same impression I get with regards to HTML 5's 
attitude to microformats.

And that's disappointing because there isn't one syntax that's going to 
be best for everyone all of the time, and there doesn't have to be a 
'winner' - publishers should be able to say whether they're using RDFa, 
and user-agents should be able to decide whether to ignore an absence of 
a profile or not. HTML is supposed to have a doctype, but that doesn't 
stop browsers from trying to parse as html anything that looks like it.
>  (X)HTML already has semantic
> features which authors can use to express their meaning such as h1, h2,
> lists, links, meta, rel, rev, etc. Therefore, all pages have metadata,
> we are just adding richer capabilities.
>
>   
That's not really convincing because the 'semantics' of html elements 
are of a different nature from the semantics of RDFa. You aren't *just* 
extending HTML's semantics, you're extending it to allow a different 
*kind* of semantics to be embedded in it - the semantics, incidentally, 
of a data model that  can  be  expressed  in many different ways. So it 
would be good  if RDFa could 'play nice' with some of those other ways.

I apologise for making my first post to this list one of dissent, and 
I'm sorry if I'm irritating you all about an issue that has already been 
laid to bed, I just think that offering at least the *option* of a 
@profile to authors is important. It  doesn't stop anyone from using or 
parsing RDFa without it, it just acknowledges that not every web page 
contains RDFa, and that RDFa isn't the only syntax for expressing RDF in 
HTML.

Thanks,


Keith

-- 
Keith Alexander
http://semwebdev.keithalexander.co.uk/blog/

Received on Thursday, 24 May 2007 11:15:42 UTC