Why RDFa profiles should be expressed in RDF

Ivan brought my attention to a discussion on Mark's objection to RDFa  
profiles expressed in RDFa.

I wanted to add my €0.02 to that discussion.

Manu summarised Mark's concerns as follows:

> #1) We have a software architecture where the foundations depend on  
> the finished product.

This could be resolved by forbidding the use of @profile inside  
profile documents, or by stating that @profile is ignored while  
processing a profile document.

> #2) It's not good RDF...it's a pattern that no-one else uses.

There are many things in RDFa that have been done nowhere in the RDF  
stack before. It is true that no one else used RDF before to express  
information needed for parsing a doc into triples. But we are talking  
about using triples defined in *one* document to affect the parsing of  
*another* document, and I have not seen an explanation why that is a  
problem or poor design. (If we were talking about triples in *one*  
document affecting the parsing of the *same* document, then I'd be  
concerned as well.)

> #3) To implement it properly you need to be able to query the triple  
> store.

I think that the proposal discussed in ISSUE-39 (expressing term  
mappings with a single triple) significantly reduces that problem (if  
you want to call it a problem). Since we talk about single triples, it  
is quite easy to build up a list of mappings while parsing, and access  
it when necessary.

> #4) We now have to maintain a vocabulary. We have all these terms  
> flying around, have to devise a namespace for them, and so on.


If the WG feels that the additional workload caused by the need to  
manage a vocabulary is an obstacle for the profile-in-RDFa approach,  
then I'd be willing to volunteer some time towards creating and  
maintaining the namespace documents and making sure they are correctly  
published (regardless of how ISSUE-39 is decided). I have some  
experience in that area and believe it's no big deal -- we're talking  
about three or four terms, aren't we?

I want to echo one response from Manu:

> Speaking more specifically, while a key-value text file would be  
> simpler, a major requirement (imho) of the RDFa Profile documents is  
> that they're human readable. By human-readable - I mean, by a web  
> designer... not a developer. It would be a shame if an RDFa Profile  
> document doesn't also include common usage information and  
> documentation about the terms and prefixes that the document  
> expresses.

I strongly agree with that point. I concede that human-readability of  
profiles can be maintained without expressing them in RDFa, e.g., by  
using special HTML attributes. I sort of would like to see a concrete  
proposal -- Mark mentioned “an RDFa document that contains only  
@prefix, @vocab and @xmlns attributes,” but I don't see how that would  
be sufficient to express term mappings.

Finally, Mark repeatedly asked variations of the following question:

> I'd love to see a justification for using RDF to express information  
> about how to abbreviate an RDF document. (And don't get me wrong --  
> there may well be some. But if we are going to add this extra layer  
> of complexity I'd like to see them.)

1. Parsimony. A profile is a (human-readable, HTML) document  
containing a simple data structure, consisting of a string-to-URI  
mapping for prefixes, a string-to-URI mapping for terms, and a default  
vocabulary URI. The whole purpose of the RDFa spec is to define a  
format for embedding such data structures into HTML pages. So why use  
yet another format?

2. Credibility. RDFa clearly *can* be used for the job of encoding  
RDFa profiles; encoding that kind of data structure is clearly within  
the space that RDFa is designed to address. But your stance is that  
RDFa is actually too complex as a solution for encoding RDFa profiles.  
If you're not even willing to use it yourself in your own spec, then  
how can you expect anyone else to believe that it's not an  
overcomplicated technology? If you argue that RDFa is too complex for  
profiles, and a simple key-value format would be better, then the same  
argument can be used against almost any possible use of RDFa.

3. Extensibility. If RDF is used to encode RDFa profiles, then you  
could easily annotate term mappings with additional processing  
information in extensions, e.g., whether a property term is optional  
or required for a resource of a given class; or what transformation  
function should be used to “clean up” the term (turn literals into  
URIs, turn plain literals into XSD types etc); or rdfs:comments and  
skos:usageNotes; etc etc

4. RDF/JSON. (This one is outside of the scope of this WG, but  
nevertheless relevant.) It's very likely that the next RDF WG will be  
chartered to develop a JSON serialisation for RDF. I believe that this  
format, even more than RDFa, would benefit from a term mapping  
mechanism. If the RDFa WG comes up with an RDF-based format for  
profiles, then the same RDF format, serialised in RDF/JSON, would be a  
no-brainer solution for RDF/JSON. I dream about being able to use  
profiles in Turtle as well, but that's probably unrealistic.

All the best,
Richard

Received on Monday, 4 October 2010 14:05:15 UTC