Re: GRDDL profile for RDF-A

+1 for all your comments, excellent post

I would add that getting rid of the profile attribute in the head 
element is no problem. You can always use link rel="profile", even, I 
would say that rel="profile" is a more orthogonal mechanism than an 
specific attribute.

Best wishes

Keith Alexander escribió:
>
> 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
>

Received on Thursday, 24 May 2007 12:26:49 UTC