Re: Another way other than @profile, @vocab or @map

I have always felt that we need a way to permit the definition of a new 
default prefix.  In fact, if you look at 
http://rdfa.info/wiki/RDFa_Vocabularies you can see the wiki page Manu 
and I started developing about it ages ago.  Toby, you even contributed 
to it!

Actually, looking back, what that proposal did was conflate a couple of 
things... but I still think it is mostly clean. I updated it to use the 
attribute name @vocab, because I agree that it is meaningful.  Note that 
in this proposal @vocab can be used to declare a default prefix, declare 
other prefix mappings, AND implies a follow-your-nose vocabulary 
extension mechanism.  Also note that in this proposal the target 
document is an RDFa document that uses the link element with a special 
@property value to define additional prefix mappings if it wants to.

I am not really trying to muddy the waters here, but I suppose I am by 
introducing yet another way of thinking about this.  The nice thing 
about this mechanism is that we could just remove the bits about 
retrieving a remote document altogether.  It is a way to extend the 
collection of prefixes and keywords, but it is not really required in my 
opinion.  Not for the use cases I can think of.

Martin McEvoy wrote:
> Hello Toby,
>
> On 19/03/2010 13:47, Toby Inkster wrote:
>> On Fri, 2010-03-19 at 12:21 +0000, Martin McEvoy wrote:
>>   
>>> @profile in this way is behaving just the same as html4 profiles..
>>>
>>> "As a globally unique name. User agents may be able to recognize the
>>> name (without actually retrieving the profile) and perform some
>>> activity based on known conventions for that profile"
>>>
>>> http://www.w3.org/TR/html401/struct/global.html#profiles
>>>
>>> In the case of RDFa the "known conventions" would be setting the
>>> default namespace for the document.
>>>      
>> Not quite the same. "name" in the quote above can be translated as
>> "URI". So when it says:
>>
>>     "user agents may be able to recognize the name"
>>
>> it means that user agents should only be doing this for URIs that they
>> recognise. Unless I'm misunderstanding your suggestion, RDFa processors
>> would be applying the profile as a default prefix whether or not they
>> recognised the URI.
>>    
>
> Yes they would be applying the profile as a default CURIE prefix 
> whether or not they recognise it, ... hmm sounds a little unsafe..  
> but isn't that what we are suggesting with the rdfa profile proposal, 
> perhaps I am misunderstanding something ;)
>
>> I don't have anything against this general technique - but I don't think
>> it's consistent with the HTML4/XHTML1.x definition of @profile, so a
>> different attribute would need to be used.
>>    
>
> I agree (now)  best to avoid @profile and use something new, like your 
> original proposal, Im glad we discussed its uses first though.
>
> http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2010Jan/0019.html 
>
>
>> A lot of the debate here has been on the syntax and model for profile
>> documents. Personally I don't think we've had enough debate on whether
>> profile documents are needed at all
>
> I agree ...
>
>>   - Martin's suggestion here is not to
>> define a profile (in the sense that we've been talking about them) at
>> all, but to just set the default CURIE prefix.
>
> Which in my mind is the simplest problem to solve ....
>
>> What exactly are the use
>> cases that show this to be insufficient? Personally, I don't think I've
>> seen any yet.
>>    
>
> :)
>
> I believe If this group can come to a decision on "how to declare the 
> default CURIE prefix" a lot of the other problems such as "prefix-less 
> tokens" and google wanting  to "bundle a bunch of existing vocabs 
> together" may have agreeable outcome to a certain extent.
>
> @vocab as new attribute name is looking pretty desirable now ;)
>
> Best wishes.
>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Friday, 19 March 2010 15:17:16 UTC