W3C home > Mailing lists > Public > public-ldp-wg@w3.org > February 2013

Re: The Intuitive/ Requirement

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Tue, 26 Feb 2013 10:57:01 -0500
Message-ID: <512CDB4D.7020608@openlinksw.com>
To: public-ldp-wg@w3.org
On 2/26/13 10:14 AM, Wilde, Erik wrote:
> hello all.
>
> On 2013-02-26 10:37 , "Henry Story" <henry.story@bblfish.net> wrote:
>> It seems accepted by the group as a requirement on the LDP specification,
>> though it would be good to make it explicit, that LDP must allow
>> implementations to follow what I would like to call the intuitive
>> requirement, nameley that:
> they should be able to follow whatever naming scheme the implementers
> happen to prefer. we shouldn't make any statements about naming
> conventions in the spec. we can, however, include recommendations and/or
> best practices in accompanying documents.
>
>> URIs MUST be opaque
>> -------------------
>> It is usually argued that this is bad because URIs must be opaque.
>> But clearly that cannot be the case or else the above turtle would be
>> illegal and the URI specification would be mistaken  since it goes into
>> great detail on this subject, as for example in
>>   http://tools.ietf.org/html/rfc3986#section-5.2.4
> this specific part of the spec is very detailed because it says how to
> resolve relative URIs against base URIs. this indeed is important, and
> you're correct that at this level, URIs do have structure: they have path
> components and these have semantics in terms of resolving relative URIs.
> but that's it, and it's different from prescribing URI patterns for
> specific resources in specific media types.
>
> but like i said above, the point you're making is a useful one and would
> be a good addition to best practices, so that implementations that want to
> use hierarchical URIs (they don't have to if they don't feel like it) have
> a good starting point.
>
> cheers,
>
> dret.
>
>
>
>
Believe or not, s/URI/URL/g makes this all simpler to understand.

A URL has specific characteristics e.g., the fact that URLs denote Web 
Documents.

A file system is comprised of files and directories (a kind of file) 
[1][2][3].

URIs denote anything. Thus, using URI in this manner ultimately injects 
the breadth of *anything* into the mix. Net effect,  it makes what 
should be simple and intuitive hard to understand.

Thus far, this has been all about modelling a RESTful mechanism for 
creating files and directories all of which you denote using URLs. Of 
course, a URL is a kind of URI, but at this juncture, we are dealing 
with the URI subClass, so best to ground the narrative appropriately via 
use of URL.

URLs should be hackable [4] while URIs should be opaque [5].

Links:

1. http://kingsley.idehen.net/DAV/home/kidehen/Public/ -- a directory 
associated with an assortment of files and sub-directories .
2. http://uda.openlinksw.com/data/turtle/ - directory associated with a 
collection of Turtle docs .
3. http://virtuoso.openlinksw.com/data/turtle/  -- ditto .
4. http://bit.ly/TZ7uNZ -- Roy's world view which is scoped to Web 
Documents bearing Web accessible content (the Data Resource)
5. http://bit.ly/SnuECw -- TimBL's world view which is scoped to the URI 
that denotes anything (including Web Documents).


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen







Received on Tuesday, 26 February 2013 15:57:28 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 May 2013 13:44:29 UTC