Re: RDFa Default Profile Management

Hi Ivan,

Ivan Herman wrote:
> So... is the problem you describe below a real problem? You bet it is. Actually, similar situation may arise with any profile. If profile 'p' includes a reference from 'foo' to 'http://bar' today and, in a few years, the authors of 'p' change the reference of 'foo' to 'http://anotherbar' then the generated triples for a file referring to 'p' will, retroactively, change. That is bad.
> 
> Let me go one step further: in some ways, I agree that profiles are bad. They bring in an uncertainty of that kind, putting the responsibility of proper vocabulary management to the publishers of profiles. I must admit that _I_ never felt the necessity of profiles for myself. I (and I presume most of us) have no problems defining the prefixes in the RDFa file which is the _only_ foolproof mechanism for URI redirection.

Likewise, my only (personal) use case for profiles, or profile like 
functionality, is to combine properties I frequently use in to a single 
vocab/profile (hopefully reusable by others).

> 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.

> 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).

> 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.

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

Received on Monday, 7 February 2011 13:01:44 UTC