Manu Sporny wrote:
So, I've butchered Shane's initial RDFa Profiles document to pieces, and
potentially Mark's ideas about RDFa Profiles (apologies in advance to
Shane and Mark). The new one can be found here and isn't meant to be
anything but a set of discussion points and proposed mechanisms for the
RDFa Profiles discussion that we will be having in the coming months.
General feedback from the community, or alternate mechanisms, would be nice:
http://rdfa.info/wiki/rdfa-profiles
Again, keep in mind that these are discussion points with some suggested
approaches. There are probably a number of issues with this RDFa
Profiles page that will hopefully be teased out via discussion.
...
I understand that many have been pressing for a different way to
associate prefixes.
However...:
- This proposal separates the declaration from the document; which means
that the HTML document isn't self-describing anymore (you need to take
referenced profile documents into account as well). This is similar to
CSS; but for CSS all that is lost when things break is styling.
- Recursion: if the consumer is expected to extract RDF triples from the
profile, can that recurse; that is, can it happen that, in order to
process a profile document, you need to process *another* profile first?
- Formats: what media types are recipients expected to be able to
extract tripes from? N3? HTML+RDF? XHTML+RDF? RDF/XML? more?
- Reliance on well-known URLs: people may be tempted to link to "public"
versions of profile documents (instead of supplying their own copy);
that would result in a similar problem as with DTDs (clients re-fetching
them over and over again).
IMHO, solutions that keep the full URIs inside the document (be it by
QNames, CURIEs, safe-CURIEs or full IRIs) are more robust and harder to
get wrong. But I understand this may be a minority position.
BR, Julian
