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.

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.

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

Received on Tuesday, 17 February 2004 11:37:25 UTC