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 <> wrote:
>>> On Thu, Jan 28, 2010 at 10:09 PM, Ross Singer <> 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
>>> have /hotpicks/
>>> resolving to 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"  :-)



Kingsley Idehen	      
President & CEO 
OpenLink Software     
Twitter: kidehen 

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