Ben Adida wrote:
Maciej Stachowiak wrote:
Microformat-defined rel and class values have their usual semantics
regardless of whether one links a GRDDL transform converting them to RDF.
How is mnot going to figure out what those semantics are to generate a
proper link-type header? Will all microformats be added to the IETF
link-type registry?
Could you clarify which specific microformat you're concerned with here?
I assume you are referring to one that defines new values for @rel?
I've read over this thread a few times, and I still haven't seen any
technical argument against the way RDFa handles @rel that is consistent
with specs prior to RDFa. We have an example with GRDDL (and also with
eRDF, though it's not a w3c spec) that @profile may define an *indirect*
way, using other elements and attributes, to interpret @rel. RDFa is no
different.
Julian argues that GRDDL is not about interpreting @rel, it's just about
extracting RDF/XML. I don't see the difference, but if one wants to draw
a line, then simply put RDFa on the GRDDL side and assume that it's
What exactly do you mean by "put RDFa on the GRDDL side"?
"just a way to extract RDF/XML." I think you'd be missing out on how
much you can get out of RDFa, but certainly if GRDDL gets a pass on
this, then RDFa should, too.
In fact, remember that RDFa also specifies @about so you can, for
example, have multiple images each with its own unique copyright
license. For link-type to do the right thing, it actually needs to fully
parse the RDFa. I'd be excited to have the link-type spec do that, but I
doubt that's within its scope. So maybe ignoring RDFa is the right
approach for link-type.
If by "link-type" you are referring to Mark's Internet Draft: there is
no conflict between it and RDF related technologies like RDFa. The HTTP
Link header does in HTTP response headers what link/@rel does inside
HTML. The issue, again, is the incompatibility of handling @rel in
different members of the HTML language family.
Best regards, Julian
