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

Hi,
RFC 3986 [http://tools.ietf.org/html/rfc3986] about URIs includes section 6 defining how to compare URIs.
The tricky facet of this section is that it states:
- if two URIs are identical character by character this is a no brainer
- if two URIs are not identical this way it could depend on the URI scheme if they are in fact identical (in 6.2.3), e.g. if resolving two different URIs lead to the same result or resource. But: how could this be checked by a parser of an ODRL document?

And to add this: if two slashes in an http URL is the same as one slash is discussed controversially: 
http://webmasters.stackexchange.com/questions/8354/what-does-the-double-slash-mean-in-urls/8381#8381 
http://www.webmasterworld.com/apache/4538262.htm ... Shows that you have to tweak Apache to accept slash-twins else http://example.com//asset:9898 would not show the same resource as http://example.com/asset:9898

My conclusion: let's aim at simply clarity in ODRL documents and aim at identical URIs character by character.

Michael

> -----Original Message-----
> From: Mo McRoberts [mailto:Mo.McRoberts@bbc.co.uk]
> Sent: Wednesday, November 13, 2013 1:38 PM
> To: Víctor Rodríguez Doncel; ODRL Community Group
> Subject: Re: odrl-ISSUE-16: Use of @base and relative URIs in examples
> [ODRL 2 Ontology]
> 
> Hi all,
> 
> Do you realise you???re arguing about the equivalent of a difference
> between???
> 
> <a href=???/foo???>foo</a>
> 
> and
> 
> <a href=???foo???>foo</a>
> 
> ???in a web page served at http://example.com/ ?
> 
> If your reading of the spec is something other than ???these are entirely
> equivalent", either the spec is unclear, your reading is incorrect, or _every_
> implementation of allegedly-conformant URI rebasing, from browsers to
> stand-alone parsing libraries, is buggy in this regard.
> 
> M.
> 
> On  2013-Nov-13, at 09:28, V??ctor Rodr??guez Doncel
> <vrodriguez@fi.upm.es> wrote:
> 
> > Hi,
> >
> > I am no expert in this topic and after reading once and again the spec I am
> still not sure...
> > But I made a small test, and checked that upon normalization,
> >
> > "http://example.com//asset:9898"
> >
> > and
> >
> > "http://example.com/asset:9898"
> >
> > happen to be equivalent. We should opt for the "canonical" form, though...
> >
> > V??ctor
> >
> >
> > El 13/11/2013 9:45, Michael Steidl (IPTC) escribi??:
> >> 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.
> >>> -----------------------------
> >>
> >>
> >
> >
> > --
> > V??ctor Rodr??guez-Doncel
> > D3205 - Ontology Engineering Group (OEG)
> > Departamento de Inteligencia Artificial
> > Facultad de Inform??tica
> > Universidad Polit??cnica de Madrid
> >
> > Campus de Montegancedo s/n
> > Boadilla del Monte-28660 Madrid, Spain
> > Tel. (+34) 91336 3672
> > Skype: vroddon3
> >
> >
> 
> 
> --
> 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 Thursday, 14 November 2013 11:25:45 UTC