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

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

Received on Thursday, 14 November 2013 13:42:24 UTC