Re: Range of URI+fragment dereference function (new issue?)

On Thu, 2002-08-15 at 13:10, Paul Prescod wrote:
> Dan Connolly wrote:
> > 
> > ...
> > 
> > But there is, I think, a fairly simple and appealing
> > architectural view in which http://example#foo
> > is in the same class as http://example, but
> > ../foo is in a very different class from
> > http://example#foo . Does this rendition of it appeal to you?
> What is the range of the URI REF dereference function?

'URI REF'? I'm not sure what you mean by that.

If the question is
	What to URIs refer to?

the answer is:
	resources. Uniform Resource Identifiers identify resources.

If the question is
	What do URI references refer to?
the answer is:
	They're abbreviations for URIs,
	which refer to resources.

> For example, the document says "In the case of a graphics format, a URI
> reference might designate a circle or spline.". Does it designate a
> "circle or spline" or circle _element_ or spline _element_.

Uh... it said 'circle or spline'; if it meant circle element,
it should have said so. Or at least it should have made
a disclaimer ala:

  "It is convenient to adopt a familiar abuse of terminology
  and identify a single triple with the graph consisting of
  the singleton set containing that triple."

Part 1 of the XML Schema spec is extremely explicit about
when it means a schema component versus when it means
an element describing a schema component. Some readers
hate this, but I'm not sure we could have been sufficiently clear

> For
> instance, given two different elements I know that they are really
> different. I can infer distinctness just by virtue of the fact that XML
> elements have unique identity.

Really? Where is XML element identity defined?
Not from the XML 1.0 spec, and not from the infoset spec.

The XML Query specs almost specified identity
for XML elements, but then the weasled out:

  Message-ID: <>
  Date: Thu, 12 Apr 2001 09:55:53 -0500
  From: Dan Connolly <>
  Subject: XML query constructors: not well-defined

WG reply:

You can tell that XML elements are distinct by looking at their
infoset properties, meanwhile, which is perhaps sufficient
for the point you were making...

> But two splines might be "the same" in
> some SVG sense. Perhaps that is inferrable from the rules of SVG or
> perhaps it needs to be explicitly asserted. Either way, identity for an
> SVG abstraction is different than identity for an XML abstraction.


> Similarly, I would expect an SVG circle to have a "radius" property
> whereas an XML "circle element" could at best have an "attributes"
> property with a "radius" attribute information item in there.
> I think that it is dangerous to declare that the referent is the SVG
> abstraction and not the XML abstraction because how then do I talk about
> the XML element?

This doesn't generalize to formats that aren't XML based. You'd
agree we want to talk about postscript pages, PNG pixels
and regions, MPEG frames, etc, no?

I agree this is an important issue, though.
In my most recent writing-and-noodling on all this,
I didn't get around to elaborating "pointing to elements
vs. pointing to things." It has come up before
in discussions of mapping XLink <-> RDF.

Hm... I wonder if TimBL touched on it in...
... no, not really...

I think this belongs on the TAG issue list.
It's been suggested that there are two kinds of dereferencing:
xlink:href-style, for pointing at parts of documents,
and rdf:resource-style, for pointing at things described
by or mentioned in documents. A new tdb: URI scheme
(thing-described-by) has been suggested.
I'm not comfortable with either of those solutions, yet,
but I agree it merits investigation.

I keep thinking
I should capture the RDF/XLink issue in a test case, but
I haven't gotten around to it yet.

> The grove view is that by default we address elements and explicitly ASK
> to address beyond elements into other layers of abstractions.

Hmm... the grove view assumes everything has element structure?

> I think
> the Web needs to formalize its view.

Maybe, but maybe not. Maybe we don't need any more constraints

> >...
> > > and if I have a resource identified
> > > by the URIRef, how do I
> > > reference a fragment of that resource (assuming it has one)?
> > 
> > OK, assuming it has one, I can coin a new URI
> > 
> >
> >         (pretend that's the MID for this message)
> > 
> > to refer to it.
> But we've lost the benefits of the HTTP URI scheme.

How so?

> If resources can
> have resources as fragments then it only makes sense that the syntax
> should have first-class support for it:
> Historically, fragments pointed at things that were NOT resources

Really? Where is that documented?
The documentation I'm aware of says that everything with identity
is a resource, so of course the things fragments point to
are resources.

> so
> there was no issue of recursion.

I don't think that changing the words used to describe a concept
makes issues go away. Either first-class syntax support for
fragment composition is and issue or it's not. I think
it is an issue, but it's acceptable, at least so far,
that the Web doesn't have it.

I think COM Monikers have complex composition; I'm not sure if
every COM Moniker is composable with every other or if
there are limits.

> -- 
> "When I walk on the floor for the final execution, I'll wear a denim 
> suit. I'll walk in there like Willie Nelson, John Wayne, Will Smith 
> -- Men in Black -- James Brown. Maybe do a Michael Jackson moonwalk."
> Congressman James Traficant.
Dan Connolly, W3C

Received on Thursday, 15 August 2002 14:55:27 UTC