I hesitate to disagree with my esteemed colleague from the UK (sorry;
listening to the US Senate; they all speak like that).
(DISCLAIMER: I am not an RDF expert.)
I appreciate your concern that we lose the ability to describe a
relationship of "role". I don't know if such a thing is important.
What I do know is that, in accordance with the general rule that RDFa
should 1) limit the duplication of data, and 2) make it as easy as
possible to annotate a document for people who only care a little bit
about the semantic web... we need to make it easy to say "this item is
of the class of things called foo". As I read the RDF stuff, that
means an rdf:type.
So... I need it to be easy to say:
<div id="curie" about="curie" role="rss:item myml:index">
<h2 property="rss:title">CURIE Syntax 1.0</h2>
<p property="rss:description">A syntax for expressing Compact
URIs</p>
<dl>
<dt>Last Recommendation:</dt>
<dd>None</dd>
<dt>Last Public Draft:</dt>
<dd><a
href="http://www.w3.org/TR/2007/WD-curie-20070307">http://www.w3.org/TR/2007/WD-curie-20070307</a></dd>
<dt>Last Editor's Draft:</dt>
<dd property="dc:date" content="2007-04-02"><a
id="curie-ED" href="curie">2 April 2007</a></dd>
</dl>
</div>
I am pretty sure that gives me the triples I want for an RSS item. If
I were so inclined, I could readily extract the relevant RSS out of
this document via RDFa.
<file:///C:/cygwin/home/ahby/htmlwg/curie>
<http://purl.org/rss/1.0/title> "CURIE Syntax 1.0" ;
<http://purl.org/rss/1.0/description> "A syntax for
expressing Compact URIs" ;
<http://purl.org/dc/elements/1.1/date> "2007-04-02" ;
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> rss:item ;
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type> myml:index .
Isn't this exactly the problem we are trying to solve? Easily adding
annotation to existing documents? And if so.... how can we continue to
support this style usage if we are not mapping role to type?
Oh - and I will ask one more question. Is it actually a bad thing that
having an additional value for role there might generate another
triple? Note my use of the special private myml namespaced role of
"index". This component of my page is part of an index of items.
That's good, right? I can use that as a role that is the target of
some xml event handler (like a special key mapping that skips between
index items) AND I could use it via RDFa to find triples related to my
index items, should that interest me. Seems like a win-win.
Mark Birbeck wrote:
Hi everyone,
As we established on the XHTML call yesterday, the role/rdf:type issue
is still not clear. There was a request for examples, but as I said on
the call, the problem is that the issue really is more to do with
making use of the triples generated, rather than with the mark-up
itself.
In particular, as I said before I'm flagging up the problem because I
want to be sure that we don't block any _future_ use-cases by saying
that rdf:type == xh:role. One such use-case is actually illustrated by
a technique that is being used in the Ajax community, an example of
which is here:
<http://www.almaer.com/blog/archives/001459.html>
What is being done here is that authors are using the @class attribute
as a hook to indicate that they want some HTML element to be used as a
widget of some type--it's called 'unobtrusive JavaScript' in the Ajax
community. So, in the example we have mark-up like this:
<div class="feedbillboard access:randomly">
...
</div>
A JavaScript process obtains a list of all the elements in the
document that have the class 'feedbillboard', and adds functionality
to the elements. It's a nice simple technique, and the only problem
with it is that the class names are not namespaced. Actually, there's
another problem which is the disturbing trend towards using the class
attribute to carry parameters for these widgets, in the form of
name/value pairs that use ':' as the separator! For example:
feedbillboard numberofentries:4 access:randomly timeinterval:4.
But let's put that aside for now, since hopefully we can propose a
better solution before it's too late. :)
Anyway, how would we do this 'properly', so to speak?
Well, the first thing we'd do is define more precisely what it is that
we're trying to achieve, and say that we want the 'div' to 'play the
role' of a billboard. Obviously we'll therefore use @role (I'll leave
aside the parameter question, for now):
<div role="almaer:feedbillboard">
...
</div>
The syntax is easy bit, but the trickyness comes when deciding what
logic to use to actually add the billboard functionality.
One way to do it is to say that all we need do is act exactly as
before, but instead of acting on @class we act on @role. That's fine,
and if that is the way to do it, rdf:type doesn't even enter into it.
But if we were to say that xh:role == rdf:type, then the way the
functionality should be added is to let an RDFa parser have a go at
the document, and then query the triples generated; we'd be looking
for all elements that have an rdf:type of almaer:feedbillboard. Of
course the problem with this technique is that you will find elements
that were added without using @role:
<link about="#b" rel="rdf:type" href="almaer:billboard" />
<div id="b">
...
</div>
The point is not that we have an ambiguity over what
'almaer:billboard' means, but that we have no way of knowing how the
rdf:type triple was added. In this example we would get the following
triples:
<#b> rdf:type almaer:billboard .
But if we use @role to mean rdf:type, we get this:
<blah> xh:role almaer:billboard .
<blah> rdf:type almaer:billboard .
Once we have added that extra triple (by defining @role to mean
rdf:type), we can never remove it--in other words, we'll never be able
to use @role to indicate something other than rdf:type. (I suppose to
put it a different way, we _lose_ the meaning of 'plays the role of',
since now all we have is the meaning 'is a type of'.)
As always, the question is whether this fits with the original
intention of @role. My feeling is it doesn't, and as you may have
noted, I'm talking myself back round to the idea that we shouldn't
make @role indicate rdf:type! Such is the nature of these things......
Regards,
Mark
On 23/04/07, Mark Birbeck <mark.birbeck@x-port.net> wrote:
Hi Steven,
On 23/04/07, Steven Pemberton <steven.pemberton@cwi.nl> wrote:
> On Mon, 23 Apr 2007 00:29:59 +0200, Mark Birbeck
<mark.birbeck@x-port.net>
> wrote:
> > The current state of play with @role and @class is that @role
> > represents a predicate of xh:role, whilst @class represents a
> > predicate of rdf:type. The main motivations were as follows:
> >
> > * we need to do _something_ with @class, since it is widely
used;
>
> Bzz! False! Just because it is widely used is not a reason to use
it. In
> fact my argument is that that is exactly the reason *not * to use
it :-)
> People expect it to mean other things. Start with a clean sheet.
But as I illustrated in my other post on semantic mark-up, @class is
definitely widely used in a proper, semantic way. Microformats is the
highest profile use, but people do know how to use it correctly. So I
believe we need to leverage that knowledge, and work out what @class
means from an RDF stand-point.
> > * we need an easy way of indicating rdf:type;
>
> Agree.
>
> > * having a 'role' of 'toolbar' is not the same as _being_ a
toolbar,
> > and so @role shouldn't
> > be used for rdf:type.
>
> I know you think this, and I have considered your explanations of
why, and
> I am still not convinced. I'm personally happy with @role being
rdf:type.
Lot's of people are happy with using @role to represent rdf:type, but
the question is about whether the whole system works if we do that,
not whether people are happy with it.
To illustrate the problem, let's say that an 'alert' is defined
somewhere as having two methods, show() and hide(), as well as a child
element which is a 'close' button. Now let's say that in some document
I discover this mark-up:
<div role="abc:alert">
...
</div>
Should I now be able to find the methods show() and hide() on the
'div' element? Or should the presence of @role on the 'div' indicate
to me that these methods need to be added?
If @role is an indicator that some kind of processing is required,
then it's clear that the 'div' is not of type 'alert' until the
processing has been done. In that case I would say that it is more
logical that the 'div' has an xh:role predicate, with a value of
'alert', but it does _not_ have an rdf:type of 'alert'.
(Contrary to what Richard is saying in his post, @role as originally
proposed had nothing to do with RDF.)
Now, the interesting thing is that if you deliver an XHTML document to
Firefox with the @role attribute set to certain values, then the
element that the attribute is on does actually acquire the methods and
properties defined for that role value. Using my simple example, if
you pass the mark-up above to Firefox, then the 'div' actually
acquires the trappings of an 'alert'.
(Hence the references to duck typing in my previous post, with which
this shares some ground.)
So the big question is, by taking the approach that an element with a
role 'becomes' an object of that type, do we mess anything up for
future use cases that we haven't thought of. I hear what people are
saying, that having @role represent rdf:type just 'feels right', but
I've not seen an explanation that seems to have been through this in
enough detail to guarantee that we are safe if we take that route.
But since I've always said I can live with @role being the carrier of
rdf:type, even though I think it is logically wrong (because exactly
_how_ wrong seems to be balanced precariously on the head of a pin) I
really don't mind if people don't want to get into the logical side of
this. Of course it would be great to see some considerations of the
question before we finally wrap this up, but it's not terrible if we
don't.
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.
--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: shane@aptest.com