RE: GRDDL profile for RDF-A

Keith,
 
Thanks for your comments. I think there are a lot of good
and important arguments to (at least) offer a dedicated RDFa profile.
 
Here is my proposal (and asking our dear chair to put it on the
agenda for our next telecon):
 
Based on a similar discussion with Dan recently [1], and looking at
the GRDDL primer [2] (section 'Referencing Via Profile Documents'),
I propose to create a dedicated RDFa profile with the following 
characteristics:
 
 + the URI is 'http://www.w3.org/2006/07/SWD/RDFa/rdfa2rdfxml'
 + the content of the page is somehow similar to [3]
 + we use Fabien's excellent XSLT [4] as the official transformation
 
Cheers,
Michael
 
 
 
[1] http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Apr/0027.html
[2] http://www.w3.org/TR/grddl-primer/#scheduling
[3] http://research.talis.com/2005/erdf/profile
[4] http://www-sop.inria.fr/acacia/soft/sweetwiki.html
 
----------------------------------------------------------
 Michael Hausenblas, MSc.
 Institute of Information Systems & Information Management
 JOANNEUM RESEARCH Forschungsgesellschaft mbH
 Steyrergasse 17, A-8010 Graz, AUSTRIA

 <office>
    phone: +43-316-876-1193 (fax:-1191)  
   e-mail: michael.hausenblas@joanneum.at
      web: http://www.joanneum.at/iis/ <https://webmail.joanneum.at/exchweb/bin/redir.asp?URL=http://www.joanneum.at/iis/> 

 <private>
   mobile: +43-660-7621761
      web: http://www.sw-app.org/ <https://webmail.joanneum.at/exchweb/bin/redir.asp?URL=http://www.sw-app.org/> 
----------------------------------------------------------


________________________________

From: public-rdf-in-xhtml-tf-request@w3.org on behalf of Keith Alexander
Sent: Thu 2007-05-24 00:48
To: public-rdf-in-xhtml-tf@w3.org
Cc: RDFa; public-grddl-comments@w3.org
Subject: 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 12:13:57 UTC