Hi Mark!
This is a late reply (I have caught up now ;)) mostly for closure. Thank you for your comments; I believe your interpretation of my thoughts were to the point. I'm glad to see agreement overall about this issue. Using @class can still be done in a completely controlled fashion if hGRDDL is pursued further (which I hope, it seems really feasible). It is interesting to reflect about these "chimeric" aspects of RDFa you mention. It is the strength of the application, but as we see in the ongoing debates, because of this nature, we have to be thorough, formulate simple (enough) rules and seek out edge cases to avoid complicating matters. (Which I think is the case, so I'm happy.) I see two somewhat different uses for RDFa. One is the general "pieces of data" case, where you expose e.g. personal, publication and similar data within a more loosely typed web page setting. The other is the "enhanced document" case, where the document and its component parts are the primary subjects about which to add precision to "expose relevance" to the Semantic Web "view of the world". (Both cases being somewhere between "rich text" and "data record".) The latter is what I and my colleagues have been (successfully so far) using RDFa for, to structure legal documents for the intent of creating a unified approach to swedish legal information (as commissioned by Verva, the Swedish Administrative Development Agency). This is a work which is now rounding up a prototyping and initial trial period, and which I hope to make a more general write-up about later this year. It has been the primary origin for my thoughts and posts here. I have used a metaphor in describing RDFa where you "use colored pens to add precision to the content". It's great when each color is unique to the point of being a URI. ;) Best regards, Niklas On 7/9/07, Mark Birbeck <[EMAIL PROTECTED]> wrote:
Hi Niklas, Very useful comments, many thanks. I hope you don't mind if I just reply to a couple of points that particularly caught my eye, in particular the following: > [snip] > > But the issue for me is that the usage of @role, as far as I can > interpret it, is to define a relation to a resource *with the subject > being the element itself*. If this is the case, @role is out. and: > [snip] > > One practical reason is that @class seems today to be about attaching > information about the element itself (akin to how I interpret @role > above). It may not be entirely clear, but considering a designer > aiming to state some stuff about a div containing a name and phone > number, '<div class="person">' is perhaps best interpreted as "this > element is a person data container". This is a very interesting point. Along very similar lines, Ben mentioned a while back that one of the things that TBL didn't like about the use of @class in RDFa was that he felt that when he uses @class in his documents, he is actually saying something about the document element itself, and not the 'Person' or 'Event' being alluded to. Your comments seem to me to be referring to exactly this issue. The compromise we made with TBL's comments was to say that only prefixed values in @class should be parsed by an RDFa parser, but in a way that is worse than parsing all values. This is because--if we use the ideas you're referring to here--we now have one range of @class values that are in reference to elements in the document, and another range of @class values that apply to meta-information. In other words we've made the attribute have two different meanings based on its value, which is not good. At the risk of seeming to be dealing with angels jumping up and down on pin-heads, I'll venture to put this issue into its RDF context. If we think first of RDF/XML, it is not actually possible in RDF/XML to say anything about the document that carries the RDF/XML. So if you have (to continue with an earlier example...sorry Ivan!): <http://blah.blah/ivan.rdf> any statement you ever make using that URI will always be about the resource Ivan, and never about the XML document itself. Now, you could say that RDFa has gone somewhat in that direction, although not quite as far. As you rightly allude to Niklas, the way we have things at the moment in RDFa is that, whilst statements are 'carried' by an HTML/XHTML document, they are not generally _about_ the document itself--they are usually about 'People' and 'Events' which are being referred to by the document. However, unlike an RDF/XML document, with RDFa it *is* possible to make statements about the document itself. RDFa gives us a chimera; it can be both a web document (an information resource in RDF parlance) and at the same time it can carry metadata about resources (equivalent to the RDF/XML side). You rightly draw attention to @role; that's a very good illustration of how we fully intended to maintain this distinction. @role was always meant to be about the ability to say things like "the purpose of this script element is to provide a hint to a user"; as you say, that's saying something about an element in a document, and is very different from saying things like "some external document is a license". So although I think we do need an RDFa 'view' on what @class and @role do, I think we're not really in a position to say quite what it should be at the moment; should these attributes only provide metadata about the information that our HTML document is 'carrying' or should they provide information about the document itself, in the way that @role was originally intended? We've been quite careful in other places to watch what we do with @id, for example, and I think your comments are a useful reminder that we should continue to take care that we don't close for the future the ability to say useful things about the document itself. > 3. Regarding a new attribute. Not remembering all suggestions, I > suggest "@instanceof" - not the least since the rdfs:comment of > rdf:type states "The subject is an instance of a class". Meshed > example: > > <div about="#jane" class="person" instanceof="foaf:Person"> > <span class="fn" property="vcard:fn">Jane Doe</span> > </div> That's about the best suggestion so far, I think. :) Regards, Mark -- Mark Birbeck, formsPlayer [EMAIL PROTECTED] | +44 (0) 20 7689 9232 http://www.formsPlayer.com | http://internet-apps.blogspot.com standards. innovation.
