Re: LDP Best Practices and Guidelines review item: Use Relative URIs

On Sun, Jul 14, 2013 at 4:17 PM, Cody Burleson <cody.burleson@base22.com>wrote:

> Team,
>
> Could you please consider reviewing the new section in the LDP Best
> Practices and Guidelines on "Use Relative URIs" and let me know if you have
> any issues with how I have interpreted the original notes from the wiki
> Deployment Guide, which WERE as follows:
> *
> OLD TEXT*
>
> See ldp-ISSUE-29 <http://www.w3.org/2012/ldp/track/issues/29> (Relative
> URIs): Relative URIs are
>
>
>
>    - crucial in creation of resources as the client cannot know what the
>    name of the to be created resource is going to be
>    - relative URIs are helpful on the server:
>       - they allow editing of information on the file system to closely
>       match the results from the web server. This makes it possible to debug
>       without needing the server to be running
>       - mappings from OO or SQL to RDF need not be encumbered with
>       information about the name of the server, which may only be available at a
>       much later point.
>
>
> *NEW TEXT*
>
> (Note: I'm not sure if my copy/paste job will come out well in all email
> clients; you can review this section in the editor's draft here:
> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html#use-relative-uris
> )
>
> Relative URIs are useful to the Linked Data Platform in much the same ways
> that relative URLs [RFC1808<https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html#bib-RFC1808>]
> have been useful to traditional web systems. Since the things referred to
> by Linked Data URIs should ideally provide a retrievable representation,
> Linked Data URIs are usually also URLs; they locate rather than just
> identify. As such, the utilitarian value of relative URLs still applies;
> especially since the Container model of the LDP promotes hierarchical
> representations.
>
> Implementers should therefore align the function of relative URIs in LDP
> with those of traditional relative URLs where possible and appropriate.
> Aside from giving developers the comfort and convenience of familiarity,
> they provide many of the same advantages.
> *Relative URIs are shorter than absolute URIs.*
>
> In many cases, this can aid development by making code and RDF easier for
> humans to read. It can also reduce the size of payloads, which in turn, can
> reduce network traffic and stress on servers, while improving response
> times for end-users.
> Example 2: Turtle RDF representation of http://example.org/container1/with absolute URIs
>
> @prefix dcterms: <http://purl.org/dc/terms/>.
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
> @prefix ldp: <http://www.w3.org/ns/ldp#>.
>
> <http://example.org/container1/>
>    a ldp:Container;
>    dcterms:title "A very simple container";
>    rdfs:member
>       <http://example.org/container1/member1>,
>       <http://example.org/container1/member2>,
>       <http://example.org/container1/member3>.
> ]]
>
> Example 3: Turtle RDF representation of http://example.org/container1/with relative URIs
>
> @prefix dcterms: <http://purl.org/dc/terms/>.
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
> @prefix ldp: <http://www.w3.org/ns/ldp#>.
>
> <> a ldp:Container;
>    dcterms:title "A very simple container";
>    rdfs:member <member1>, <member2>, <member3> .
> ]]
>
> *Relative URIs can make resources more portable.*When information which
> is already known from the context of the base resource's retrieval is
> ommited, there can be less information to modify when that information
> changes. This can make moving resources to new servers or to a new position
> in a containment hierarchy easier.*Relative URIs are convenient during
> development.*During development the scheme and network location
> information in a URI may either be unkown or likely to change. The commonly
> used 'localhost' for example, is better expressed by the server name or a
> domain name. Developers often experience less hassle by ommiting this
> information. Additionally, the hierarchy implied by a relative URI may be
> mimicked in a server file system, which can help developers find and work
> with information, even the server isn't running.*Relative URIs are
> convenient during development.*During development the scheme and network
> location information in a URI may either be unkown or likely to change. The
> commonly used 'localhost' for example, is better expressed by the server
> name or a domain name. Developers often experience less hassle by ommiting
> this information.*Relative URIs support arbitrary, machine-generated URIs.
> *RESTful URLs are often defined by a pattern of hierarchical
> 'collections', which clients interact with in very logical ways. For
> example, when creating a new resource the client does not typically know
> the name of the resource until after a successful POST to a collection's
> URL. A POST to /people/ for example, may create the resource /people/1.
> LDP Containers are such collections whose URIs can benefit from the same
> model, which in some implementations, may actually be crucial.
>
>
> Note that I changed the URI for the container from
>
> <http://example.org/container1>
>
>
> to
>
> <http://example.org/container1/>
>
>
> ...as I believe that we may also note that as a guideline, given Henry's
> example found here:
> http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0071.html
>
> +1 This looks inline with changes I made to example to follow this
guidance as well.  Just a note that ISSUE-50 resolution may expand on this
a bit too, but think your last point covers it some.  Perhaps we need to
add another "guidance" item from issue-50 that warns that servers may mint
URIs that aren't nested under the current container and relative references
from content such as "../sibling" my not resolve as expected.

Also there are a few spelling errors: ommiting => omitting, ommited =>
omitted, unkown => unknown,

- Steve Speicher


> --
> Cody Burleson
> Enterprise Web Architect, Base22
> Mobile: +1 (214) 537-8782
> Skype: codyburleson
> Email: cody@base22.com
> Blog: codyburleson.com
>
> * <http://base22.com>*
> *
> *
> *Check my free/busy time.<http://www.google.com/calendar/embed?src=cody.burleson%40base22.com&ctz=America/Chicago%20>
> *
>
>
>