LDP Best Practices and Guidelines review item: Use Relative URIs

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

-- 
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>
*