Re: RDFa Default Profile Management

On Feb 7, 2011, at 14:00 , Nathan wrote:

> Hi Ivan,
> 

[snip]
> 
>> But. And this is a big 'but'. The sad reality is that this does not really work in practice. People will forget to put the prefix declarations, or they will screw it up my misspelling the URI-s. Hence the necessity of profiles and hence (in my view) the necessity of a default profile. Just as people do not produce valid XHTML (hence the necessity for lax rules around HTML, ie, HTML5) they do not put the namespaces either. As an example, I have looked at some pages that use the Facebook terms; even reputable sites like CNN do not do it. This example is for Facebook; but if we want a wider adoption of RDFa in HTML, then we have to rely on people forgetting this. Either we ignore the problem and then we will have lots of problems with non-valid RDFa (eg, we cannot extract triples from CNN's pages) or we construct a sub-optimal or, if you prefer, dangerous solution that would cover most of the use cases. This is where default and non-default profiles come into the picture. I h
> old my nose, but...
> 
> Indeed, I've considered your big but, and I guess ultimately I'm just unsure whether we should be specifying the "default profile" when library implementers will most likely include much fuller and more (temporarily) useful profiles themselves.
> 

Maybe, but we should not reinforce this model. That means that, I, as an RDFa author, would not know what to rely on, and therefore interoperability goes down the drain. We should not optimize in this direction.


>> Your solution would require authors to put a @profile in their file. From that point of view, there is no difference between doing that or adding prefix declarations. It does not happen today (see CNN) what makes you think it will happen tomorrow? In my view, if we do not have a default profile, we have not solved the issue.
> 
> Well, that or each version of RDFa comes with a default profile for that version (which doesn't change).
> 

That came up on one of our telco, but that would not cut in my view. I do not expect, once the work of this group is over, to touch RDFa any time soon. Say, 5 years. So let us suppose we had a fixed and frozen default profile of 5 years ago. That would not include prefixes for sioc, skos, void, og, bibo, just to name a few of the vocabularies that are widely used today. The default vocabulary would be useless, most of the time.

>> The next question is how would a default profile change. I think that is the responsibility of the policy of change. You say that, at (t1) there is a well known vocabulary for which there is a social convention to use the prefix "foo". Maybe what we also have to say, before we add 'foo' to the default profile, that this has to be requested by the authors of the corresponding vocabulary. That request should include a commitment of no change, ie, that 'foo' will always refer to "http://example.org/2008/02/vocabs/foo/". If the vocabulary maintainers want to make an update to .../2015/01/foo/, then they have to request another prefix, "foo2". Social conventions are not out of the blue; they are crafted and 'directed' by those who create and maintain vocabularies. If the authors of the "http://example.org/2008/02/vocabs/foo/" cannot or do not want to take a no-change commitment then, well, that particular prefix does not get into the default vocabulary. I have the feeling that 
> by disallowing a default profile we would throw the baby out with the bath water.
> 
> Disallowing a default profile may be a bit strong, as in I'd personally hope that library implementers will provide a rich default profile of well known prefixes (I know I provide over 100 in my libs), and I guess worry that by specifying a default profile ourselves, we're potentially constraining the default profiles libraries will implement (as in, we're sending a message only x,y,z prefixes should be in there, and if they include more people can complain and get them removed because they aren't "compliant" with the 'default profile') and similarly opening ourselves up to the issues mentioned previously in a rec track spec.

There is nothing that disallows a library implementer to add a whole bunch of additional prefixes if they want. But the default profile gives you the minimum everybody can rely on!

Ivan

> 
> I guess my personal preference would be something like:
> 
> "implementers should provide default mappings for prefixes x,y,z to uris a,b,c; this mapping is also available in a profile _here_; libraries are encouraged to provide rich default profiles of their own and work with other library developers to synchronise their profiles"
> 
> Best,
> 
> Nathan


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf