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

Kingsley Idehen wrote:
> 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"  :-)

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


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