RE: Heads up: RFC2996bis, possible problem for RDF

>I don't think we should be suggesting that the meaning of a URI might differ
>from that of a URI with a slightly different spelling.
>
>We have remained silent on the relationship between
>
>http://foobar and HTTP://foobar:80/
>
>and I think we should remain silent. The advice in RFC 2396 bis to avoid
>forms like the latter of these two is good.

But the primary issue here is, if they ARE used then they should NOT 
be considered to be identical or interchangeable. Substituting one 
form of a URI for another could produce unforseeable and potentially 
catastrophic consequences for any SW reasoner.

>
>For example using
>
>http://www.w3.org/1999/02/22-rdf-syntax-ns
>
>in place of
>
>http://www.w3.org/1999/02/22-rdf-syntax-ns#
>
>does not work operationally, but I would not commit myself to making that a
>semantic truism.
>
>However, I would not object to being a co-signatory on your suggested
>textual change.

I agree with Graham that this is a potentially serious problem that 
we should nip in the bud. I also would like to be a co-signatory on 
the proposed textual changes; Graham, please include me. I 
particularly like the inclusion of the phrase " for purposes of 
retrieval" as it acknowledges that URIs have other purposes.

Pat

>
>Jeremy
>
>
>>  -----Original Message-----
>>  From: w3c-rdfcore-wg-request@w3.org
>>  [mailto:w3c-rdfcore-wg-request@w3.org]On Behalf Of Graham Klyne
>>  Sent: 17 February 2004 16:53
>>  To: Jeremy Carroll; rdf core
>>  Subject: RE: Heads up: RFC2996bis, possible problem for RDF
>>
>>
>>
>>  At 15:30 17/02/04 +0100, Jeremy Carroll wrote:
>>  >This does not look disastrous to me.
>>  >
>>  >In RDF URIrefs ending in # (i.e. with explicitly empty fragment) only
>>  >regularly occur as namespace names. All possible uses of such URIrefs
>>  >involve qnames which give them a non-emtpy fragment part.
>>  >
>>  >The text in question
>>  >
>>  >"URI producers and normalizers should omit a delimiter if the
>>  component it
>>  >delimits is empty"
>>  >
>>  >uses a "should" not a "MUST", and is hence sufficiently weak.
>>
>>  Yes, but the text also seems to claim that it is always safe to apply the
>>  normalization.  That is my concern.  Section 6.1 says "...  while
>>  strictly
>>  avoiding false positives".
>>
>>  >We perhaps could suggest modifying the text:
>>  >[[
>>  >
>>  >, with one exception: a double-slash delimiter indicating an authority
>>  >component should not be removed, even when the authority is empty, since
>>  >doing so can lead to misinterpreting the path.
>>  >]]
>>  >http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#normalize-empty
>>  >
>>  >to
>>  >[[
>>  >. A first exception is: a double-slash delimiter indicating an authority
>>  >component should not be removed, even when the authority is empty, since
>>  >doing so can lead to misinterpreting the path.
>>  >A second exception is: a common idiom in RDF/XML uses URI references with
>>  >empty fragments as XML namespace names.
>>  >]]
>>
>>  I think it would also apply to empty path and query components,
>>  so I'm not
>>  happy to just pick out empty fragments as a second exception.
>>
>>  >The overall normalization rules in section 6
>>  >http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#comparison
>>  >inevitable create a many positive matches that are not honoured in RDF
>>  >concepts. Like XML namespaces we chose the simplest possible
>>  definition of
>>  >equality: string equality. The overall tone of section 6 ought to respect
>>  >such a choice.
>>
>>  Yes.  I'm waiting to see what response to my comments, but I
>>  think I might
>>  suggest that the text:
>>  [[
>>  Therefore, comparison methods are designed to minimize false negatives
>>  while strictly avoiding false positives
>>  ]] -- (section 6.1)
>>
>>  be something like
>>  [[
>>  Therefore, comparison methods are designed to minimize false negatives
>>  while strictly avoiding false positives when used for purposes of
>>  retrieval.
>>  ]]
>>
>>  (This echoes the earlier comment "URI comparison is performed in
>  > respect to
>>  some particular purpose" [section 6 intro], and I think provides the
>>  necessary escape route for RDF and XML namespaces and maybe other
>>  purposes
>>  to which URIs are pressed.)
>>
>>  #g
>>  --
>>
>>  > > -----Original Message-----
>>  > > From: w3c-rdfcore-wg-request@w3.org
>>  > > [mailto:w3c-rdfcore-wg-request@w3.org]On Behalf Of Graham Klyne
>>  > > Sent: 17 February 2004 13:17
>>  > > To: rdf core
>>  > > Subject: Heads up: RFC2996bis, possible problem for RDF
>>  > >
>>  > >
>>  > >
>>  > > I've just reviewed:
>>  > >
>>  > >     http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html
>>  > > Modified: 16 February 2004 11:36:15
>>  > > Size: 167.42 KB (171437 bytes)
>>  > >
>>  > > Which has recently been "last called" in the IETF URI
>>  informal group in
>>  > > preparation for an IESG last-call request, per:
>>  > >    http://lists.w3.org/Archives/Public/uri/2004Feb/0082.html
>>  > >
>>  > > I am concerned that the empty component normalization rules may be
>>  > > troublesome for RDF.  My review comments are at:
>>  > >    http://lists.w3.org/Archives/Public/uri/2004Feb/0094.html
>>  > >
>>  > > The specific example raised is:
>>  > >
>>  > > [[[[
>>  > > Section 6.2.2.3:
>>  > > I'm concerned about empty component normalization:
>>  > > In RDF usage, the URIs:
>>  > >      http://example.org/
>>  > > and
>>  > >      http://example.org#
>>  > > would result in quite distinct resource identifiers, e.g. in:
>>  > >
>>  > > [[
>>  > > Triples of the Data Model in N-Triples Format (Sub, Pred, Obj)
>>  > >
>>  > > <http://www.w3.org/RDF/Validator/run/foo>
>>  > > <http://example.org/prop> "value" .
>>  > >
>>  > > The original RDF/XML document
>>  > >
>>  > > 1: <?xml version="1.0"?>
>>  > > 2: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>>  > > 3:   xmlns="http://example.org/">
>>  > > 4:   <rdf:Description rdf:about="foo">
>>  > > 5:     <prop>value</prop>
>>  > > 6:   </rdf:Description>
>>  > > 7: </rdf:RDF>
>>  > > ]]
>>  > >
>>  > > and
>>  > >
>>  > > [[
>>  > > Triples of the Data Model in N-Triples Format (Sub, Pred, Obj)
>>  > >
>>  > > <http://www.w3.org/RDF/Validator/run/foo>
>>  > > <http://example.org#prop> "value" .
>>  > >
>>  > > The original RDF/XML document
>>  > >
>>  > > 1: <?xml version="1.0"?>
>>  > > 2: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>>  > > 3:   xmlns="http://example.org#">
>>  > > 4:   <rdf:Description rdf:about="foo">
>>  > > 5:     <prop>value</prop>
>>  > > 6:   </rdf:Description>
>>  > > 7: </rdf:RDF>
>>  > > ]]
>>  > >
>>  > > (RDF triples generated by http://www.w3.org/RDF/Validator/)
>>  > >
>>  > > Are distinct RDF graphs, even though the URIs are equivalent under the
>>  > > normalization rules given.
>>  > > ]]]]
>>  > >
>>  > > #g
>>  > >
>>  > >
>>  > > ------------
>>  > > Graham Klyne
>>  > > For email:
>>  > > http://www.ninebynine.org/#Contact
>>  > >
>>  > >
>>
>>  ------------
>>  Graham Klyne
>>  For email:
>>  http://www.ninebynine.org/#Contact
>>
>>


-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 18 February 2004 16:53:06 UTC