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

Re: RDFa Profiles, terms, and predicates (oh my!)

From: Shane McCarron <shane@aptest.com>
Date: Fri, 23 Jul 2010 12:45:37 -0500
Message-ID: <4C49D541.8020303@aptest.com>
To: Ivan Herman <ivan@w3.org>
CC: RDFa WG <public-rdfa-wg@w3.org>
I have tightened the conformance language in the current source version 
of the spec.  You can see it at 
http://www.w3.org/2010/02/rdfa/sources/rdfa-core/#s_profiles



On 7/23/2010 12:05 PM, Shane McCarron wrote:
> Among your excellent points, you say:
>
> On 7/23/2010 8:59 AM, Ivan Herman wrote:
>> This model is nice because the target URI can refer to RDFa or to any 
>> other RDF formats, ie, instead of a recursive call it can also go and 
>> invoke any RDF parser that the underlying library provides.
>>
>
> I think this is the key reason that relative URIs won't work.  While 
> we REQUIRE that an RDFa Profile be defined in RDFa, that profile might 
> have other formats and might return a JSON representation, for 
> example, if the requestor indicated in the HTTP Accept header that 
> format was okay.  In that situation, clearly we can't assume any 
> special processing of the returned data.
>
> On the other hand... since the server controls the content of that 
> profile, obviously the server (or profile author) could ensure that 
> the alternate representations were in their appropriate forms; this 
> would include ensuring that a URI mapping was absolute.  That 
> requirement is in my mind independent of whether we require that an 
> RDFa Processor handle relative URIs in object literals associated with 
> 'rdfa:uri'.  We control the horizontal and the vertical here. If we 
> want to mandate special processing for a specific predicate, we can 
> obviously do that.  We already do it for the RDF:XMLLiteral datatype 
> for example.
>
> Anyway... just because we can do a thing doesn't mean we should do a 
> thing.  Requiring that the object literal associated with 'rdfa:uri' 
> be an absolute URI seems the cleanest solution.  I again bow to your 
> wisdom.  Thanks for clearing this up.  I will add text to Section 9 so 
> the next idiot doesn't ask this again!
>

-- 
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, 23 July 2010 17:46:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:07 GMT