[whatwg] A Selector-based metadata proposal (was: Annotating structured data that HTML has no semantics for)

On 20 May 2009, at 23:10, Tab Atkins Jr. wrote:

>> Stuffing multiple discrete pieces of information makes things  
>> harder for
>> parsing, harder for authoring tools and harder for authors. In RDFa,
>> each attribute performs a simple role - e.g. @rel specifies the
>> relationship between two resources; @rev specifies the  
>> relationship in
>> the reverse direction; @content allows you to override the
>> human-readable text of an element. Combining these into a single
>> attribute would not make things simpler.
>
> You're leaving out @about, @property, @resource, @datatype, @typeof,

All of which have similarly simple usages:

@about = sets the URI for the thing we're talking about
@property = specifies what property the element's text represents
@resource = provides a link which is the object of @rel / subject of  
@rev
@datatype = specifies the type of data for an element with @property
@typeof = specifies the type for a new resource

> and numerous implicit uses of @href or @src,

@href == @resource (but at a lower priority, so latter can override)
@src == @about (but at a lower priority, so latter can override)

> along with with implicit
> chaining with contained nodes.  Please don't misrepresent the
> simplicity of RDFa - it's a generic metadata extraction method, and is
> rather complex.  So is CRDF, of course, but that's not disputed.

Each attribute is rather simple and has a simple syntax. Chaining  
them together becomes more complicated, I don't dispute that - but  
chaining together anything tends to increase complexity significantly  
(consider the implications of nested elements on onclick handling in  
Javascript - the result is event bubbling, which is hardly an easy  
concept for newcomers to Javascript).

But as each individual attribute is simple, and we can get some small  
gains without complex chaining, then basic uses of RDFa become pretty  
easy.

e.g.

     <img alt="Crazy Foo!" src="foo.jpeg" rel="license"
          resource="http://example.com/license.html">

Something that anyone can do to easily. Becoming familiar with simple  
cases will help them get to grips with how the attributes work, so  
they're more familiar if they feel the need to mark up more complex  
data.

> (Also, the argument against @rev is still going strong - in the RDFa
> in XHTML document, section 6.3.2.2, the foaf:img relation is misused
> in @rev, causing the RDF to state that Mark is an image of the <img>
> resource!  @rev really is too confusing for standard use - just add
> inverted @rel values when necessary.)

Both usages of foaf:img in the RDFa in XHTML document seem to be  
correct. I think you may be thinking of Mark's draft RDFa tutorial.  
He explained on the RDFa task force that this was due to his  
misunderstanding foaf:img rather than misunderstanding @rel.

Indeed, FOAF has three different terms (img, depiction, depicts) for  
connecting an image to the thing depicted in the image, so it's not  
hard to get them mixed up. This is precisely why @rev is needed - to  
prevent having to define separate depicts/depiction, maker/made,  
primaryTopic/isPrimaryTopicOf terms. Having just one term to describe  
the relationship, and reversing the direction by moving it from @rel  
to @rev, makes vocabularies smaller and simpler.

> We are going to have to massively disagree on this point.  ^_^  I love
> CSS syntax.

So do I, but CRDF as defined is no more like CSS in terms of syntax  
than C or Perl are - they share the curly braces and semicolons, but  
not much else.

> It is rarely, if ever, necessary to set multiple <img> elements to the
> same @src or @alt.

I'm thinking of things like a table which has a check-mark column  
with a green tick image repeated all the way down, or a traffic-light  
indicator column with red, green and perhaps amber images indicating  
different statuses. I quite often see such things in web applications.

-- 
Toby A Inkster
<mailto:mail at tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Wednesday, 20 May 2009 16:29:44 UTC