Re: Question about "paths as URIs" in the BBC RDF

Nathan wrote:
> Yves Raimond wrote:
>   
>> On Thu, Jan 28, 2010 at 10:44 PM, Yves Raimond <yves.raimond@gmail.com> wrote:
>>     
>>> On Thu, Jan 28, 2010 at 10:09 PM, Ross Singer <rossfsinger@gmail.com> wrote:
>>>       
>>>> I'm not sure this is what the spec actually says.  xml:base deals with
>>>> relative URIs (which may be either a relative or absolute path, per
>>>> RFC2396 section 5:
>>>> "relativeURI   = ( net_path | abs_path | rel_path ) [ "?" query ]").
>>>>
>>>>         
>>> Then I am getting very confused: shouldn't the example in
>>> http://www.w3.org/TR/2001/REC-xmlbase-20010627/#syntax have /hotpicks/
>>> resolving to http://example.org/today/hotpicks/? Also, according to
>>> the doc Dan mentioned, if it was the case, does that mean something
>>> like "/path" gets resolved to "location of the document/path"?
>>>       
>> I think section 5.2 may be relevant:
>>
>>       If the scheme component is defined, indicating that the reference
>>       starts with a scheme name, then the reference is interpreted as an
>>       absolute URI and we are done.  Otherwise, the reference URI's
>>       scheme is inherited from the base URI's scheme component.
>>
>> And 5.1.2 defines the base URI as:
>>
>>     If no base URI is embedded, the base URI of a document is defined by
>>    the document's retrieval context.  For a document that is enclosed
>>    within another entity (such as a message or another document), the
>>    retrieval context is that entity; thus, the default base URI of the
>>    document is the base URI of the entity in which the document is
>>    encapsulated.
>>
>> So I really think xml:base is not necessary in that context?
>>
>> Cheers,
>> y
>>
>>     
>
> I have got one kind of big question; why not just be more verbose and
> include full URIs? if it ensures that the data is always perfect and
> full abstracted from the notion of HTTP (touchy subject?)[1] then why
> not do it?
>
> I would be very interested in hearing arguments in favour of using paths
> instead of full URIs rather than how to handle the eventualities where
> its decided to use paths. Additionally I had a conversation about this
> with Mark Birbeck in regards to RDFa and not setting a base in the
> document a few weeks back, some interesting points were raised - will
> see if I can dig out the convo from my history and summarise his points
> in a short mail.
>
> [1] Very recently I've had a subtle, personal, view change about "linked
> data" - namely that it's the grounding for something which can be
> expanded in the future, in this view precedence goes to dereferencable
> URIs with a scheme and EAV triples; the linked data concept fits even if
> you change the scheme to say xmpp:// and serialize in xmpp+rdf; or in
> future formats and using schemes we haven't even thought of yet -
> binding a concept to a technology / protocol / transport / specific
> serialization format inherently limits future expansion and
> optimisation. Thus whilst I'm massively in favour of REST and HTTP for
> the time being, I'm also acutely aware that the concept must be able to
> transcend both REST and HTTP in the future. If that makes sense (?)
>
> Many Regards,
>
> Nathan
>
>
>   

As long as your chosen scheme supports content negotiation, the crown in 
the "HTTP Jewels"  :-)



-- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter: kidehen

Received on Thursday, 28 January 2010 23:50:49 UTC