W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > March 2010

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

From: Shane McCarron <shane@aptest.com>
Date: Fri, 19 Mar 2010 10:16:31 -0500
Message-ID: <4BA3954F.2030903@aptest.com>
To: martin@weborganics.co.uk
CC: Toby Inkster <tai@g5n.co.uk>, Ivan Herman <ivan@w3.org>, RDFa WG <public-rdfa-wg@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:46 UTC