RE: odrl-ISSUE-16: Use of @base and relative URIs in examples [ODRL 2 Ontology]

Hi Mo,
actually 5.2.3 Merge Paths of RFC3986 tells more about this issue than 5.1.1:
It writes down:
The pseudocode above  (in 5.1.x) refers to a "merge" routine for merging a
   relative-path reference with the path of the base URI.  This is
   accomplished as follows:
   o If the base URI has a defined authority component and an empty
      path, then return a string consisting of "/" concatenated with the
      reference's path; otherwise,
   o  return a string consisting of the reference's path component
      appended to all but the last segment of the base URI's path (i.e.,
      excluding any characters after the right-most "/" in the base URI
      path, or excluding the entire base URI path if it does not contain
      any "/" characters).

How the components of a URI are split up is shown in section 3 of the RFC. A URI like http://example.com/ has an authority component of "example.com" and a path of "/", therefore the second bullet of 5.2.3 applies.
>From my reading this makes
mergedURI = "http://example.com/" + "/asset:9898" = "http://example.com//asset:9898" 
... which is not the same as http://example.com/asset:9898 in the explanation. And that's my point.

Michael

> -----Original Message-----
> From: Mo McRoberts [mailto:Mo.McRoberts@bbc.co.uk]
> Sent: Tuesday, November 05, 2013 11:39 AM
> To: ODRL Community Group
> Subject: Re: odrl-ISSUE-16: Use of @base and relative URIs in examples
> [ODRL 2 Ontology]
> 
> Hi Michael,
> 
> I don?t believe this is correct ? I?m about 99% sure that @base behaves as
> <base href=???> does in HTML; the strings are not strictly concatenated, but
> instead the possibly-relative URI is rebased against the value of @base. The
> Turtle spec specifically cites RFC3986 section 5.1.1, "Base URI Embedded in
> Content".
> 
> e.g., if you had:
> 
> @base <http://example.com/foobar> .
> @prefix foaf: <http://xmlns.com/foaf/0.1/> .
> 
> </baz#id> a foaf:Agent .
> 
> then the triple is expanded to:
> 
> <http://example.com/baz#id> <http://www.w3.org/1999/02/22-rdf-syntax-
> ns#type> <http://xmlns.com/foaf/0.1/Agent> .
> 
> Live example of the above:
> 
> Turtle: http://ptah.bencrannich.net/2013/misc/test
> 
> N-Triples:
> http://lodscope.parthenon.org.uk/index.text?uri=http://ptah.bencrannich.n
> et/2013/misc/test
> 
> So while it?s true that the URIs have one character more than they strictly
> need, it doesn?t make any difference to the parsing result.
> 
> M.
> 
> On  2013-Nov-05, at 09:29, ODRL Community Group Issue Tracker
> <sysbot+tracker@w3.org> wrote:
> 
> > odrl-ISSUE-16: Use of @base and relative URIs in examples [ODRL 2
> Ontology]
> >
> > http://www.w3.org/community/odrl/track/issues/16
> >
> > Raised by: Michael Steidl
> > On product: ODRL 2 Ontology
> >
> > All the Turtle examples in the Ontology draft are using @base this way:
> > @base <http://example.com/> .
> > @prefix odrl: <http://w3.org/ns/odrl/2/> .
> > ...
> > odrl:target </asset:9898> ;
> > ....
> >
> > The description of this example states that the URI for the asset is
> http://example.com/asset:9898
> > Reading the Turtle specs I conclude that the strings of @base and the
> relative URI are concatenated making http://example.com//asset:9898
> which is not the same as described.
> > Wouldn't it be better to omit the leading slash in the relative URIs?
> >
> >
> >
> 
> 
> --
> Mo McRoberts - Analyst - BBC Archive Development,
> Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
> MC3 D6, Media Centre, 201 Wood Lane, London W12 7TQ,
> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E
> 
> 
> 
> -----------------------------
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and
> may contain personal views which are not the views of the BBC unless
> specifically stated.
> If you have received it in
> error, please delete it from your system.
> Do not use, copy or disclose the
> information in any way nor act in reliance on it and notify the sender
> immediately.
> Please note that the BBC monitors e-mails
> sent or received.
> Further communication will signify your consent to
> this.
> -----------------------------

Received on Wednesday, 13 November 2013 08:45:53 UTC