W3C home > Mailing lists > Public > public-lod@w3.org > January 2010

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

From: Nathan <nathan@webr3.org>
Date: Thu, 28 Jan 2010 23:54:58 +0000
Message-ID: <4B6223D2.3030705@webr3.org>
To: Kingsley Idehen <kidehen@openlinksw.com>
CC: Yves Raimond <yves.raimond@gmail.com>, Ross Singer <rossfsinger@gmail.com>, Dan Brickley <danbri@danbri.org>, Linked Data community <public-lod@w3.org>
Kingsley Idehen wrote:
> 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"  :-)

ahh I'm not changing any scheme for now; but somebody in 100 years may
feel it's beneficial :-) don't want to run before I can walk / (crawl)!

regards
Received on Thursday, 28 January 2010 23:56:40 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:24 UTC