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

Re: A rose by any other name is just as thorny...

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 27 Mar 2010 23:15:28 -0400
Message-ID: <4BAEC9D0.1060703@digitalbazaar.com>
To: RDFa WG <public-rdfa-wg@w3.org>
On 03/27/2010 10:24 PM, Shane McCarron wrote:
>>> But @vocab isn't used for loading keywords (that's @profile) - it's used
>>> for setting the default prefix. If CURIEs in the default prefix are
>>> always mapped to lower-case, then things like <div
>>> vocab="http://xmlns.com/foaf/0.1/" typeof="Person"> won't work.
>> We may want to say that rel/rev are always mapped to lower-case since
>> they are legacy attributes. Everything else is case-sensitive.
> I don't think we can do this.  It would mean that datatype='MyDatatype'
> and rel='MyDatatype' would not map to the same URI.  I think we have to
> say all terms are mapped to lower-case if we want this to hang together.

... but we can't do that? See Toby's typeof="Person" comment above. What
am I missing?

Yes, you couldn't use the same vocabulary term in datatype and rel and
expect them to map to the same URL if we have such a think as a default
@vocab value. However, if we have a default @profile document, we could
differentiate based on @rel/@rev.

Although, how often does markup use the same vocabulary term in datatype
and rel? Can we think of any real-world examples?

We might just have to say if you use @vocab and then specify rel="NEXT",
tough... bad triple. Unless, we:

1. Require dereferencing of the default @profile document for the
2. Have a rdfa:caseinsensitive value that we can assign to vocabulary

Although, even that is gross. I'm starting to lean toward requiring the
RDFa Processor to know what's in the default @profile document (via
dereferencing, caching, backup service, hard-coding, etc.).

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarming Goes Open Source
Received on Sunday, 28 March 2010 03:15:58 UTC

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