Manu Sporny wrote:
...
Here are a few:
hReview, xFolk, hCard, hCalendar, hAudio and other Microformats that use
rel-tag, rel-purchase, rel-nofollow, rel-directory, rel-enclosure,
rel-home, and rel-payment
* hReview uses rel-tag for tags and scalar tags
* xFolk uses rel-tag to build a distributed remote resource tagging
construct
* hCard can use rel-tag for categories
* hCalendar can use rel-tag for categories
* hAudio uses rel-purchase for purchase information, rel-enclosure for
downloadable files.
Thanks for the pointer. I'm using hCard myself, but haven't used rel
values for it yet.
In practice, @profile is not used and thus the semantic meaning of these
terms is ambiguous and only truly "understood" by a Microformats parser.
A non-Microformats parser would ignore these @rel values, thus creating
a situation where a Microformats-aware parser would extract different
meaning from a document vs. a non-Microformats-aware parser. The
situation is the same with a GRDDL-aware parser vs. a non-GRDDL-aware
parser.
However, I don't think that's Julian's point. I believe that his point
is that, because of CURIEs, you have a two-stage process instead of a
one-stage process.
For CURIES, you must:
1. Read the value in @rel.
2. Lookup the prefix mapping and append the reference to the prefix.
For GRDDL, you must:
1. Read the value in @rel.
2. Process the @rel value via XSLT.
Hm, no. Unless I'm missing something.
In GRDDL, you pass the document to the specified transformation, and end
up with a bunch of RDF.
For Microformats, non-CURIEs, etc., you must:
1. Read the value in @rel.
Is that your issue, Julian? That because of CURIEs/RDFa, you have to do
more now to determine what @rel really means?
Yes. Using a safe-CURIE wouldn't have prevented that, but at least it
wouldn't break URIs in rel values.
BR, Julian
