Re: Namespaces wihtout "#" Was: Few CWM Bugs

----- Original Message -----
From: "Graham Klyne" <GK@ninebynine.org>
To: "Tim Berners-Lee" <timbl@w3.org>
Cc: <www-rdf-interest@w3.org>
Sent: Monday, November 26, 2001 11:59 AM
Subject: Re: Namespaces wihtout "#" Was: Few CWM Bugs


> At 10:39 AM 11/26/01 -0500, Tim Berners-Lee wrote:
> >Fortunately, the fragment ID allows us to refer to something defined
> >or described by the document, and that can be quite abstract.
>
> Hmmm... this feels like an uncomfortable overloading of fragment
identifier.
>
> Before responding to this, I checked out your
> http://www.w3.org/DesignIssues/Fragment.html (which, BTW, has been updated
> recently but there's no record of the update)...

It was changed last in Feb.  Sorry the logs are not accessible.
Log appended. It was updated in JigEdit which alas captures no comment.

> [Remaining quotes are from: http://www.w3.org/DesignIssues/Fragment.html]
>
> >The fragment identifier is a string at the end of a URI which identifies,
> >within a Web document, a part or view to which one refers.
>
> [...]
>
> >Axiom
> >The significance of the fragment identifier is a function of
> >the MIME type of the object
>
> >Fragment identifiers for RDF identify concepts
> >The semantic web has information about anything. The fragment identifier
on
> >an RDF (or N3) document identifies not a part of the document, but
whatever
> >thing, abstract or concrete, animate or innanimate, the document
describes as
> >having that identifier.
>
> I have a couple of problems with this:
> (a) this is rather at odds with the earlier definition of identifying
> something "within a web document".

Well, isn't it the same concept of "whatever a local identifier stands for
in the
language of the document"?  The early web langauges used identifiers to
identify bits of human-readable stuff.

> (b) It's not clear to me that RDF is unequivocally associated with a MIME
> type.   What's the MIME type of RDF embedded in an XHTML document?

For most questions of semantics, the XML mime types defer to the
specification of the namespace.   However,  there is not a very clean
hand-off from the XML spec to a namespace spec in the case of the
fragment identifier.  For example, most generic XML applications
will happily use an XML ID to refer to a chunk of XML (whatever
it means, if it means anything).  Implicitly SVG uses it to refer to a
circle,
for example, but that is really because there is no ambiguity
in that nothing needs the option of referring both to the XML chunk
and to the circle.  RDF could I suppose do the same, say that
any reference in the semnatic web langauges to foo.edf#bar
refers to the concept bar, not to a chunck of syntax.

> >It is important, on the  Semantic Web, to be clear about what is
> >identified. An http: URI (without fragment identifier)
> >necessarily identifies a generic document. This is
> >because the HTTP server response about a URI can deleiver a rendition of
(or
> >location of, or apologies for) a document which is identified by the URI
> >requested.  A client which understands the http: protocol can immediately
> >conclude that the fragementid-less URI is a generic document.  This is
true
> >even if the publisher (owner of the DNS name) has decided not to run a
server.
> >Even if it just records the fact that the document is not available
online,
> >still a client knows it refers to a document.  This means that
identifiers for
> >arbitrary RDF concepts should have fragment identifiers.  This in term
means
> >that RDF namespaces should end with "#".
>
> [Aside:  this last bit is new new me;  it's very disconcerting when these
> ideas seem to pop out of the woodwork.]

I would refer to it more as a process of condensation than popping.
It is an iterative attempt to satisfy the edge constraints and be
internally consistent.

> [...]
> >User awareness of the form of a reference
> >Clearly when a fragment ID is generated and associated with a URI which
is
> >generic in any way (language, version, etc as well as content-type), then
> >there is a possible failure of the fragment-id refers to something which
is
> >not defined in any specific instance.  It would be appropriate for a
client,
> >when generating a link (or bookmark, etc) to provide the user with a
choice
> >of
> >A bookmark to the whole living document, or
> >A bookmark to a specific part of a "dead" version;
> >Intermediate combinations.
> >As both these options are meaningful and useful, they will have to
surface
> >at the user interface level.
>
> Maybe this last point indicates part of the confusion I feel here:  with
> RDF, I think it's fair to say that that which is referenced does *not*
have
> to surface at the UI level -- it's part of an identifier that may be
> exchanged between systems without regard for user presentation or
> containing document.

Yes, talking about the UI only works for UI languages.

> It seems to me that RDF uses fragment identifiers in a different way than
> web retrieval applications.

If you mean that UI languages, yes.  (I regard     cwm
http://www.foo.com/bar.rdf
as a web retreival application!)

> Is it really harmful to just say that RDF is
> different in this respect?

I think we can say that UI languages and SWeb languages differ in the
sorts of things they identify.

That doesn't make one right and the other wrong.

>  I can't help feeling that this attempt to fit
> RDF interpretation into some variant of the web browsing mould will
> generate more confusion than clarity.

We  are, rather, fitting both the RDF and the web browsing into
a general web architecture -which we have to do.

> #g
>
>
> ------------
> Graham Klyne
> GK@NineByNine.org
>
___________________________________________________________---
revision 1.12 [edit log]
date: 2001/02/15 22:26:23;  author: timbl;  state: Exp;  lines: +15 -8
(timbl) Changed through Jigsaw.
----------------------------
revision 1.11 [edit log]
date: 2001/02/15 22:05:11;  author: timbl;  state: Exp;  lines: +2 -1
(timbl) Changed through Jigsaw.
----------------------------
revision 1.10 [edit log]
date: 2001/02/15 22:03:42;  author: timbl;  state: Exp;  lines: +3 -1
(timbl) Changed through Jigsaw.
----------------------------
revision 1.9 [edit log]
date: 2001/02/15 21:58:07;  author: timbl;  state: Exp;  lines: +7 -1
(timbl) Changed through Jigsaw.
----------------------------
revision 1.8 [edit log]
date: 2001/02/15 21:47:14;  author: timbl;  state: Exp;  lines: +30 -44
(timbl) Changed through Jigsaw.
----------------------------
revision 1.7 [edit log]
date: 2000/09/08 20:16:57;  author: timbl;  state: Exp;  lines: +162 -143
(timbl) Changed through Jigsaw.
----------------------------
revision 1.6 [edit log]
date: 1998/03/04 17:24:58;  author: timbl;  state: Exp;  lines: +0 -0
(timbl) Changed through Jigsaw.
----------------------------
revision 1.5 [edit log]
date: 1998/03/04 17:24:47;  author: timbl;  state: Exp;  lines: +2 -0
(timbl) Changed through Jigsaw.
----------------------------
revision 1.4 [edit log]
date: 1998/03/04 17:22:51;  author: timbl;  state: Exp;  lines: +2 -1
(timbl) Changed through Jigsaw.
----------------------------
revision 1.3 [edit log]
date: 1998/03/04 17:19:01;  author: timbl;  state: Exp;  lines: +21 -21
(timbl) Changed through Jigsaw.
----------------------------
revision 1.2 [edit log]
date: 1998/01/29 23:28:11;  author: timbl;  state: Exp;  lines: +143 -107
(timbl) Changed through Jigsaw.
----------------------------
revision 1.1 [edit log]
date: 1998/01/29 23:21:17;  author: timbl;  state: Exp;
(timbl) Catch up a bit! tim

Received on Monday, 26 November 2001 13:18:57 UTC