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

Tim,

this is a somewhat delayed response to your earlier message;  I was hoping 
that I could come to some deeper understanding of the explanations you 
offered.  I'm not sure that I have...

At 01:18 PM 11/26/01 -0500, Tim Berners-Lee wrote:
> > >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.

I can't dispute this, but it doesn't really help me understand a consistent 
way to interpret fragment identifiers...

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

This last sounds to me like a way to interpret a fragment identifier that 
does not follow the MIME type axiom quoted at the start of this message.

> > >It is important, on the  Semantic Web, to be clear about what is
> > >identified.

Quite. I don't yet have this clarity...

[...]

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

?? *is* a generic document?  Wouldn't that be references one (in the web 
retrieval sense)?  Or denotes one (in a formal semantic sense)?

For example, consider http://id.mimesweeper.com/MIMEsweeper/4.2/:  does it 
denote the HTML document that links to a description of its intended use, 
or the namespace thus described?  (For the purpose of considering this 
question, consider that I *could* have defined the namespace identifier 
without a trailing '#'.)

[...]
> > [...]
> > >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.

Yes, good.

[A side-issue, probably a distraction:

So where do we stand if we have an language that is *both* a SWeb language 
and a UI language?  I am thinking of a system that uses RDF to describe 
content for both machine and interpretation purposes;  e.g. the RDFWEB 
project (http://www.rdfweb.org) comes close to this.  My point is that if 
we allow different interpretations, how can we know what what is intended 
in any given context?

]

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

Yes, we have to do this.

My experience in designing software systems is that if I attempt to 
overload a single concept to serve fundamentally different purposes, I end 
up with strains in the architecture that lead to lack of clarity about home 
some functions should behave, and general implementation difficulties.  My 
experience is that the Right Thing to do is to acknowledge that there are 
different concepts and to distinguish them in the resulting design.

I came into this exchange expressing a concern about overloading of 
fragment identifiers, which has not been allayed.

In doing software designs I try to reduce the number of distinct concepts, 
look for common ideas and merge them, which is what I think is happening 
here with URI fragment identifiers.  But when an idea is being required to 
serve different purposes, I also find that it is simpler in the long run to 
separate the design element (e.g. split a class into two classes, use two 
variables instead of one, etc.).

In the case of URI fragment identifiers, I am concerned that their use in 
web browsing languages to describe "views" does not sit comfortably with 
--is not truly the same concept as-- their use in Sweb languages to 
indicate sub-concepts within some document or schema.  Trying to make them 
the same seems to be creating "fault lines" in the web architecture, 
exemplified by discussions like this.

I think we've no real option but to continue using the URI fragment syntax 
with RDF, but I think a clearer account is needed of how this use relates, 
or doesn't relate, to its use in web browsing.  At the RDF-IG face to face 
meeting in Boston earlier this year, I understood you to acknowledge that 
the set of things identified by URI+fragments in RDF is not identical to 
the set of things identified by the same syntax when web browsing.

To my mind, fragment identifier use in RDF is an extension of the URI -- a 
string of the form URI+fragment is an identifier that is handled (in RDF) 
just like a bare URI.  The proposed model theory 
(http://www.w3.org/TR/rdf-mt/) makes no distinction for interpretation 
fragment identifiers.  I view that URIs without fragment identifiers can 
identify the same things for browsing and Sweb applications, providing a 
substantial common ground in web architecture.  But I find it hard to 
imagine a common account of fragment identifier usage that is consistent 
with current usage and understanding -- hence my concerns about "overloading".

#g


------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<Graham.Klyne@Baltimore.com>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------

Received on Sunday, 9 December 2001 12:29:01 UTC