Re: resource ambiguities

> [...] musing about 'XML Events talk about qNames,

The interesting thing about XML Events setting this oft'-raised
discussion in motion is that XEvents is sub-universal; that is, the
listener element in XEvents is supposed to be a universal construct
for people to use across all applications, and yet it begs off to a
higher domain - XML namespaces - in order to provide the extensibility
and universality mechanism. So while in the problem domain *of* XML
Events, not defining a namespace structure is actually fine, in the
range of applications for which XML Events are going to be used, a
namespace structure must be defined. If XML Events are ever to be used
as part of a "system" (in the handbook sense), then they really need
these things to happen.

[...]
> A problem is evidenced in that we don't have an adequate
> theory for how URI-references bearing a #fragment part
> relate to pure URIs without a #fragment part, as regards
> what they refer to.

It's quite simple to determine the framework for such a theory, since
it is set out quite neatly by RFC 2616, 2396, and the REST
dissertation... but the handing off of fragment semantics to media
type specifications makes it tricky to go any further.

And then there are the "consistency of ID space across conneg",
"meaning in XML", and other spin-off debates. A never ending pile of
discussions.

> The principal missed opportunity here is in not distinguishing
> and encapsulating the "that described by" indirect reference
> to an abstract concept [...]

It may be a missed opportunity, but it's not through a lack of trying.
Grounding the meaning of a document in the Web is something that TAG
*must* surely address. As TimBL put it to Sandro on #rdfig:-

[[[
14:54:07 <tim-lurk> Sandro, the URI spec is the one which defines the
relationship between a  URI and its meaning.
14:54:28 <tim-lurk> For URIs starting with "http:", it hands off to
the HTTP spec.
14:54:50 <tim-lurk> The HTTP spec allows format negotaiation, and then
hands off to the MIME type registry.
14:55:10 <tim-lurk> The MIME type registry fopr application/xlm hands
of to the XML spec.
14:55:28 <tim-lurk> The XML spec hands off to the namespace URI.
14:55:35 <tim-lurk> Goto 1
]]] - http://ilrt.org/discovery/chatlogs/rdfig/2001-10-24.txt

In fact, there's a break in the cycle - the XML spec hands off to the
XPointer specification.

[...]
> The dual reference, invocation of a document as an acceptor,
> is primitive and has no dependency on the datedness or
> undatedness of the reference; it should be implemented in a
> standalone fashion that is mix and match with dating.
>
> But this is the semantics that I, at least, was anticipating when
> I let the 'role' parameter in XLink go through as a URI-reference.

Interesting; especially with Aaron within earshot. The use of URI-Refs
in XLink rather than QNames was, IMO, a questionable decision. I don't
think that there's a document type in the world that supports the
naming of XLink relationships as discrete resources, except (perhaps)
XML RDF, but I see no mandate from the XLink groups in modelling it
that way. In other words, the XLink specification does not ground any
ontology (for talking about the role attribute etc.) in the Web using
a metadata standard, which seems broken to me.

[...]
> The point is that the machinable description of an abstract
> notion is in general a complex utterance. To identify one
> relationship type one refers to a small scope within a _larger_
> utterance; [...]

O.K., but "naming for uniqueness" is not what people have in mind when
they use URIs and URI-references. The temptation of using HTTP space
to say oh-so-much more is too great; it's the Web.

The sub pattern in your argument is quite neat, and it corresponds to
the old (?) saying, "there are no semantics on the Semantic Web". The
semantics come from the interpretation of the information that you
have given a local rule-base, or built-in processor semantics. It's
the principia of cognitive science. I used to pitch a modified version
of the argument against people when I first became aware of the
situation as-is on the Web.

But it's not fully practical, because it's so closed world. The TOII
can *never* be achieved to perfection - you will always find some
problem when systems collide... the trick is in identifying the
problems beforehand, and minimzing the damage caused. One way to do
that is to be consistent in the way that you deploy your
identification schemes... and that consistency does not appear on the
Web today. That's the problem. That's why the specifications are
broken.

The choices are basically restricted to the following:-

* URI
* URI-view
* QName, URI ns
* QName, URI-view ns

A fragURI is basically a QName with a very strict structure:-

   [ :resource <http://www.w3.org/>;
     :fragment "news" ] .

The semantics of which are given in the URI RFC. There is no reason
why another similar scheme couldn't work just as well. One possible
solution to the identification problem in RDF is to say that
http://example.org/#blargh is not a URI-view at all, but a new form of
identifier that parses to the following:-

   [ :resource <http://example.org/>;
     :name "blargh" ] .

I actually think that would be a viable and sensible solution. (Aaron,
are you listening? "%23" indeed...)

> [...] To make the references one must indicate both the
> context capturing all dependencies of the definitive
> utterance (white of fried egg in image), and the scope of
> the definitive utterance as isolated within that context (yolk
> of egg in image).

I like the model, and it's clear, but I'm not sure how it helps. The
semantics-in-context of an identifier aren't quite as clear cut IMO;
they have fuzzy edges. Let's take XLink and XEvents as the examples.
They both tell you quite clearly what to expect of the @role and
@event attribute values within the context of the relative
specifications. But, put them with any other application (even created
by the same person that defined the values in the first place) using
the same identifiers, and sometimes you don't even have a way to
express whether the references are the same or different. That is
certainly true of XEvents, which is why I raised the issue, and it
seems to be fairly true of XLink for the definition problem that I
raised above.

> A naked atomic infoPoint such as the pts: URI proposal
> in incapable of capturing an abstract notion.

ESL puts an end to that problem:-

   http://www.ietf.org/internet-drafts/draft-palmer-esl-uri-00.txt
   http://infomesh.net/2001/09/draft-palmer-esl-uri-00.txt

[...]
> > [1] There are many arguements on RDF IG about the
> > nature of resources...

s/arguements/arguments/

[...]
> The fact is that not all things worth referring to have a persistent
> identity. Example: search URLs. And not all external references
> can tolerate an arbitrary 'resource' at the other end.

It is reasonable to assert that one given representation will
correspond to a resource at any given time: RFCs for example. As for
the search URI debate... I still do not agree on that matter. The
resource that is being identified may not be as nominal as most people
would expect for other resources, but it is still quite clearly a noun
that is addressed. Search engines do not break REST architecture.

> All Web resources belong to this class of service offerings. URIs
> are discriminants which help you narrow what or which service
> you would access if you use this URI as a key in a service request
> of some sort.

But the protocols for doing that should be well defined - you don't
want a browser to guess how to do an HTTP GET every time you request
that it do so, and you don't expect it to have to consult the "Web"
through some other recognized channel. GET is a well defined verb on
the Web. POST too. You don't need very many of them until you have a
grand system.

> We need to recognize that one needs to be able to refer
> categorically to a service sought without a persistent identity
> attached. Only once a delivery-of-service transaction has
> been booked with a specific supplier is there a persistent
> identity for the reservation.

I have no problem with you chaining a set of nouns and verbs together
to make a recipie... I do have a problem if you try to hide that in a
noun bag. That's what HTTP does, and that's why it's so difficult for
people to "get", no pun intended.

I think the one resolution that we need to come to is on the semantics
of (at least!) W3C specifications, w.r.t. URIs and QNames. We need to
get the structures defined, and structures put in place for evolution
of languages. We need to stop thinking that we're exploring the Web,
and start re-writing it as a consistent interoperable entity.

Meanwhile, I'll continue to flip a coin to choose my namespaces.

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://purl.org/net/swn#> .
:Sean :homepage <http://purl.org/net/sbp/> .

Received on Saturday, 8 December 2001 16:07:40 UTC