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

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

From: Ivan Herman <ivan@w3.org>
Date: Fri, 23 Jul 2010 15:59:28 +0200
Cc: RDFa WG <public-rdfa-wg@w3.org>
Message-Id: <2D81260B-47CE-4260-BAFF-3F4B8DAC77DD@w3.org>
To: Shane McCarron <shane@aptest.com>

On Jul 23, 2010, at 15:13 , Shane McCarron wrote:

> I will of course bow to your RDF wisdom on the whole issue of rdf:term and rdf:uri.  But I feel pretty strongly that we should permit the object literal that is associated with rdf:uri to be a relative URI.  To my mind there is no reason to not support this - it isn't 'messy' in that we obviously know the current base, and RDFa Processors already obviously have to convert relative URIs into absolute URIs all the time.  Moreover, there are obvious economies in terms of authoring AND an increased ease of use for RDFa Profile authors - my profile is portable.  You can grab it, add to it, make it your own, and if I was using relative URIs for my items they will now be relative to their new home.  That's a big win.
> 

I will have to think about this a bit more...

I see the points you raise. But an RDFa processor is usually prepared, internally, to handle relative URIs for, well, real URIs. But not for literals.

To be specific in my case (I believe this is a fairly typical one). Say my distiller parses file 'A', hits a @profile, goes out and (recursively) calls out to itself, so to say, to extract triples from that file (say, 'B'). The recursive call results in a separate graph (say, graph-B); the recursive stack is popped, and the level handling 'A' has graph-B to work with. It then examines the content of graph-B with some simple but fairly standard (RDFlib) calls to find the right triples and continues handling 'A'. 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.

graph-B will contain literals for URI-s. So what you are saying is that, when the content of graph-B is handled, and the content is a relative URI, that should be completed to become an absolute one. But what is the base? You can say it is the address of file 'B', ie, the @profile value, and one can then generate a nice absolute URI. But what if 'B' includes an explicit @base? Because B is handled by a standard RDFa (or turtle or RDF/XML) processor, that value is gone by the time graph-B is generated and the (recursive) parser for B ceases to exist. Ie, some sort of an out-of-band mechanism has to be found for the recursively called parser to return the URI to the caller. 

It may be simple but I am not sure at this moment whether it is...

Ivan


> Is there an RDF reason that a relative URI should not be permitted here?
> 
> On 7/23/2010 3:40 AM, Ivan Herman wrote:
>> On Jul 22, 2010, at 23:28 , Shane McCarron wrote:
>> 
>>   
>>> Quick follow-up.  When using the predicate 'rdfa:uri', the object literal needs to be a URI.  Presumably it can be a relative URI:
>>> 
>>>   <p id='myTerm' about="#myTerm"><span property='rdfa:uri'
>>>   content='#myTerm'><span property='rdfa:term'>myTerm</span></span></p>
>>> 
>>> If not... we should really say so.  If so.... we should probably say that too. And make it clear what the relative URI is resolved against (current base?).
>>> 
>>>     
>> Which is messy! I would prefer to say (and indeed, say it) that this should be an absolute URI.
>> 
>> ivan
>> 
>> 
>> 
>>   
>>> On 7/22/2010 4:02 PM, Shane McCarron wrote:
>>>     
>>>> I was working on my (implied) action item to update our vocabulary document so that it is an RDFa Profile, and I ran into something odd.  The rules for an RDFa Profile are pretty simple [1].  Shoehorning the required predicates into our existing pattern in the vocab document is a little daunting though.  I don't want to break what is already there (in case someone is depending upon it)... Here is that pattern:
>>>> 
>>>> <dt id="alternate" about="#alternate" typeof="rdf:Property">alternate</dt>
>>>> <dd about="#alternate" property="rdfs:comment"
>>>>          datatype="xsd:string"><span>alternate</span>   designates alternate
>>>>          versions for a resource.</dd>
>>>> 
>>>> 
>>>> Each term is defined that way.  All of our terms are defined within a containing bucket like this:
>>>> 
>>>> <div id="relrev-properties" about="#relrev-properties" typeof="rdf:Bag">
>>>> 
>>>> <div about="#relrev-properties" rev="rdfs:member">
>>>> 
>>>> Anyway.... our rules [1] require that in order for a term to be defined, it must be the common subject of two predicates; rdfa:term and rdfa:uri.  I completely understand why this is an attractive general case model.  I can map ANY term to ANY URI.  However, in reality, I expect that most vocabularies will be like ours - self-contained.  In other words the vocabulary document will define the term, and the URI for the term will be within that same document.  In the case above, for example, the URI for the term 'alternate' is http://www.w3.org/1999/xhtml/vocab#alternate.
>>>> 
>>>> With all this in mind, and in the spirit of never duplicating data needlessly in an RDFa document, I propose that we modify the RDFa Profile rules slightly.  That we say a term is defined by an 'rdfa:term' predicate.  That the term itself is the object of that predicate, and the URI is the object of an 'rdfa:uri' predicate on the same subject if one is provided.  Otherwise, the URI is the same as the subject of that predicate.
>>>> 
>>>> Questions?  Comments?
>>>> 
>>>> [1] http://www.w3.org/TR/rdfa-core/#s_profiles
>>>> 
>>>>       
>>> -- 
>>> Shane P. McCarron                          Phone: +1 763 786-8160 x120
>>> Managing Director                            Fax: +1 763 786-8180
>>> ApTest Minnesota                            Inet: shane@aptest.com
>>> 
>>> 
>>> 
>>>     
>> 
>> ----
>> 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
>> 
>> 
>> 
>> 
>> 
>>   
> 
> -- 
> Shane P. McCarron                          Phone: +1 763 786-8160 x120
> Managing Director                            Fax: +1 763 786-8180
> ApTest Minnesota                            Inet: shane@aptest.com
> 
> 


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







Received on Friday, 23 July 2010 13:59:08 GMT

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