Re: New RDFa Profiles document (first pass)

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

Received on Wednesday, 13 May 2009 08:57:14 UTC