Re: Default prefix in RDFa 1.1 Core (Re: Editor's Drafts Updated)

On Apr 1, 2010, at 20:03 , Shane McCarron wrote:

> 
> 
> Ivan Herman wrote:
>> Section 9 says: "RDFa the 'default prefix' mapping is http://www.w3.org/1999/xhtml/vocab#."
>> 
>> First of all, I think this statement is not for RDFa 1.1 Core and should be moved to RDFa 1.1 XHTML. But I begin to wonder how we handle these default prefixes...
>>  
> I disagree.  I think it is entirely appropriate for us to define the 'default prefix' - that is, the mapping to use with ':next'.  In this way we are confident there will always be SOMETHING that works.  In a world where people can replace the collection of defined terms, change the default vocbulary, etc, being able to say rel=':next' is a comfort, at least to me.

There are two different things: having a default prefix is fine with me. What I think I object to is to keep that default prefix being xhtml which, well, is completely irrelevant for, say, SVG.


>> My understanding is that this default prefix applies to CURIE-s of the form ':something'. We do have a mechanism now, via @vocab, for CURIE-s of the form 'something'. I wonder whether we should not merge these two notions. (I know this has been discussed before...)
>>  
> I don't think this is necessary or desirable at this time.
>> I am also a bit worried for the various language specific things. A specific language can define:
>> 
>> 1. default prefix
>>  
> It can?  I did not intend to permit this in RDFa Core.  I will check.  Let's assume that it can't.

See my comment above


>> 2. top level @vocab value
>>  
> Yes - the default vocabulary
>> 3. set of terms and prefixes via a default @profile
>>  
> Yes.  And this is scoped and cumulative. 
>> 4. additional attributes and modification on the processing rules
>>  
> Yes.
>> I am a bit worried about deployment difficulties; how would an implementation follow that? 
>> Currently the @profile document can only handle #3. I do not think there is really a way to handle #4; my initial reaction is that XML dialect authors should be discouraged to do #4, actually (SVG does not do it, for example).
>>  
> Actually, I do not think the document as currently written allows Host Languages to extend the collection of attributes that are involved in triple creation.  Why do you think this?

Ok, that is related to my comment on @href/@src. In my way of thinking those are xhtml specific


>> A possibility is to extend the possibilities of @profile to define @vocab (getting a bit convoluted, though) or #1. Then we could have some sort of a registry that binds, eg, media types to profiles that an implementation can consult regularly...
>> 
>> To be discussed, I suppose...
>>  
> I had considered this, and I don't mind the idea that an RDFa Profile document could define the default vocabulary as well.  Of course, in that case it would be overriding any local default vocabulary the user had defined previously.  Presumably you are concerned about implementations discovering *which* collection of rules (e.g., RDFa Profile) should be in effect for a given document.  This is indeed an issue, since we have no announcement mechanism that anyone is willing to mandate.  I don't have a solution for that general problem yet.  However, solving that problem solves this whole issue I think.

Yes, that is my issue: how would a processor discover those things. Note that if we are seriously considering a default profile, than the issue is identical.

I think I have already referred to the xpointer registry mechanism:

http://www.w3.org/2005/04/xpointer-schemes/

and we could do something like that for default profiles, using media types as a differentiating factor. Just a thought...

Ivan



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


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