- From: Nathan <nathan@webr3.org>
- Date: Thu, 28 Jan 2010 23:31:56 +0000
- To: Yves Raimond <yves.raimond@gmail.com>
- CC: Ross Singer <rossfsinger@gmail.com>, Dan Brickley <danbri@danbri.org>, Linked Data community <public-lod@w3.org>
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
Received on Thursday, 28 January 2010 23:34:49 UTC