[whatwg] A Selector-based metadata proposal (was: Annotating structured data that HTML has no semantics for)
Toby A Inkster
mail at tobyinkster.co.uk
Wed May 20 16:29:44 PDT 2009
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>
More information about the whatwg
mailing list