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

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,


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