- From: Michael Steidl \(IPTC\) <mdirector@iptc.org>
- Date: Thu, 14 Nov 2013 18:44:49 +0100
- To: "'ODRL Community Group'" <public-odrl@w3.org>
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