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