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

By the code you are right but conclusions from it are surprising - at first sight:
Our case:
Base URI = http://example.com/
Relative path = /asset:9898
T.authority = Base.authority --> example.com
T.scheme = Base.scheme --> http
T.path = /asset:9898
This makes a final URI http://example.com/asset:9898 - ok.

This example shows a possibly surprising result:
Base URI = http://example.com/odrl/
Relative path = /asset:9898
T.authority = Base.authority --> example.com
T.scheme = Base.scheme --> http
T.path = /asset:9898
The result is also http://example.com/asset:9898 as the code
if (R.path starts-with "/") 
completely avoids the use of base.path.

I don't want to know how many people looking at the base URI and the relative path would have quickly known that. One could argue in web server terminology that /asset:9898 apparently starts at the root directory of a host but many semantic people simply apply the rule "append a relative path to the base URI and the result is the full URI".

Therefore I want to go back to my proposal: let's keep things simple and avoid relative paths with a leading slash as people looking at the ODRL web pages are interested in ODRL and not in normalizing URIs.

Michael

> -----Original Message-----
> From: Mo McRoberts [mailto:Mo.McRoberts@bbc.co.uk]
> Sent: Thursday, November 14, 2013 2:57 PM
> To: Michael Steidl (IPTC)
> Cc: ODRL Community Group
> Subject: Re: odrl-ISSUE-16: Use of @base and relative URIs in examples
> [ODRL 2 Ontology]
> 
> it’s not T.path = merge(Base.path, R.path) because that code path is never
> executed, that line is the sequence for where R.path does *not* start with a
> slash.
> 
> At start:
> 
> Base.path => “/"
> R.path => “/asset:9898"
> T.path => undefined
> 
> if (R.path starts-with "/") then
>         T.path = remove_dot_segments(R.path);
> 
> (R.path _does_ start with “/“, because it’s “/asset:9898")
> 
> Therefore:
> 
> Base.path => “/“
> R.path => “/asset:9898”
> T.path => “/asset:9898"
> 
> M.
> 
> On  2013-Nov-14, at 13:41, Michael Steidl (IPTC) <mdirector@iptc.org> wrote:
> 
> > Mo,
> > I have read 5.2.2 else I would not have posted about 5.2.3 yesterday:
> > In the case of our example the relevant code line is:
> > T.path = merge(Base.path, R.path);
> > And 5.2.3 discussed this merge function.
> > As outlined yesterday the merge as defined by 5.2.3 leads to
> > mergedURI = "http://example.com/" + "/asset:9898" =
> "http://example.com//asset:9898"
> >
> > Michael
> >
> >> -----Original Message-----
> >> From: Mo McRoberts [mailto:Mo.McRoberts@bbc.co.uk]
> >> Sent: Thursday, November 14, 2013 2:14 PM
> >> To: Michael Steidl (IPTC)
> >> Cc: ODRL Community Group
> >> Subject: Re: odrl-ISSUE-16: Use of @base and relative URIs in examples
> >> [ODRL 2 Ontology]
> >>
> >> Okay, the big issue here appears to be reading RFC3986 but not reading
> the
> >> section relevant to dealing with relative-URI references — section 5.2.2.
> >>
> >> Specifically (where ’T’ is the target, ‘R’ is the relative-URI:
> >>
> >>        if (R.path == "") then
> >>              T.path = Base.path;
> >>              if defined(R.query) then
> >>                 T.query = R.query;
> >>              else
> >>                 T.query = Base.query;
> >>              endif;
> >>           else
> >>              if (R.path starts-with "/") then
> >>                 T.path = remove_dot_segments(R.path);
> >>              else
> >>                 T.path = merge(Base.path, R.path);
> >>                 T.path = remove_dot_segments(T.path);
> >>              endif;
> >>              T.query = R.query;
> >>           endif;
> >>
> >> That is: if relative-path is not-empty and relative-path starts with “/“, then
> >> the target path is the result of removing any ‘.’ and ‘..’ segments from the
> >> relative-path.
> >>
> >> In our case, the relative-path is “/asset:9898” which is both non-empty,
> starts
> >> with “/“ and contains no dot segments. Therefore, the target URI’s path is
> >> the same as the relative-path: /asset:9898.
> >>
> >> M.
> >>
> >> On  2013-Nov-14, at 11:25, Michael Steidl (IPTC) <mdirector@iptc.org>
> wrote:
> >>
> >>> 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.
> >>>> -----------------------------
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> 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.
> >> -----------------------------
> >
> >
> >
> 
> 
> --
> 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 17:45:22 UTC