resource ambiguities

Believe it or not, your musing about 'XML Events talk about qNames, but
namespaces don't give us the necessary relationships between names' dislodged
this old rumination from my work-in-progress heap.  The fact is that no,
namespaces don't capture the relationships; and yes, we need them.  The
relationships come from a graph comprising names and assertions.  Namespaces
are by the strongest available agreements that are widely shared,
indefinite as
to the pertinent assertions.  We need to be able to apport assertions with the
names.  And it has to be a definite graph for a reliable capture or sharable
definition of the relationship.  More below.

** identifying acceptors; a.k.a. "duality is convenient"

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.  But that statement of the problem is not
the definition of the solution space.

The principal missed opportunity here is in not distinguishing and
encapsulating the "that described by" indirect reference to an abstract
concept
(open acceptable-set) through a documented description of the concept
(de_facto
accept-pattern).  This as_acceptor reference-mode distinguisher is a
[required?
optimal?] primitive in putting instances and acceptors in a common frame of
reference.  Format specifications, along with a class of similar schemata
(utterances defining a pattern class by composite expressions employing a
pattern calculus), are document instances that are applicable as
document-instance acceptors.  [The class acceptable by schemas includes open
spaces and not just compact documents, but that nicety is not essential to the
point, here.]  It is helpful to distinguish the mode of application in the
reference, as_instance or as_acceptor, or we can't get started.

Larry Masinter articulated this relationship reasonably clearly in his
Internet
Draft on dated URIs by way of the 'tdb' variant.

http://www.ietf.org/internet-drafts/draft-masinter-dated-uri-00.txt
http://lists.w3.org/Archives/Public/uri/2001Aug/0034.html

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.  Not URI,
URI-reference.  Check the syntax.  That those wishing to define relationship
acceptors could do so by isolating the particular referend in an IDentified
entity inside an XML, SGML or HTML document, and use that dedicated
section-reference by #fragment-bearing URI-reference as the referend in
XLink.role designation.

The sense of 'role' in X-Link is to apport an assertion or climate of
assertions.  For 'apport' read 'import as applicable.'

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; the smallness of the small reference
is to gain uniqueness, to isolate one relationship from a meta-relation
relating mulitiple notions; and the large reference to incorporate a definite
collection of meta-relationships capturing inter_alia the indicated meaning of
the thing designated in the small reference.  The content of a dictionary is
not in the symbols, but in the binding to the expansions.  No abstract notion
is defined in isolation.  It is defined by a definitive collection of
relationships to other notions.  To set up the context within which the
definition can be compactly articulated, there is a lot of other utterance
that
must be placed in the context of the specific clause that defines the
individual notion to which one wishes to refer.

So reference to an 'abstract notion' -- an acceptable-set creating an
equivalence class of concretions of this abstraction -- is properly in
fried-egg form.  There are two nested horizons.  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).  A
#fragment-bearing URI-reference is well suited to this task if the author of
the schema or specification to be referenced is warned in advance of the
patterned referend that they need to export from their document for
purposes of
precision in reference.

A naked atomic infoPoint such as the pts: URI proposal in incapable of
capturing an abstract notion.  It imposes no constraint on what utterances
about that abstract node are included in the portable collection of knowledge
that is to be applied elsewhere.  An abstract notion can be usefully
defined by
a prescribed collection of associations with other notions.  Each distinct
subgraph of a relative-assertion graph such as RDF space which contains some
given abstract node (URI) is a different abstract notion.  The URI itself does
not capture this variation, or identify any of them.

A reference to a nominative point (name) in the context of a defined
[connected, connected to the name in question] graph of names and assertions
constitutes a shareable abstract notion.  A nominative point without freezing
this climate of assertions does not.  It is an instant invitation to the
classical 'semantic' confusion of different speakers using the same sign to
indicate different senses.

Boolean logic has taken us too far in computation today for us to think
that we
can do without the duality that it presents.   Count me on the
antidisestablishmentarian side as regards duality in the logical structure of
computation and the semanticization of the Web.

Al

Note:  "duality in convenient ":  here in the etymological sense.  Framing
relationship category definition in a dual-space pattern leads us to suitable
outcomes.  cf. French: _convenable_, IIRC.

-- old message

[kidnapped off EARL discussion on ER list.]

At 05:54 PM 2001-04-25 +0100, Sean wrote:
>
>How about "Resource"... they put that in RDF, and it seems to mean
>absolutely nothing as far as I can tell [1] :-)

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

AG:: There is a Mexican standoff here that is preventing progress.

Tim describes resources are one class with one characteristic: they have a
URI.  Any Web resource that makes an external reference is supposed to do
so by
URI in a way that accepts any URI, any Web resource.  All resources have
persistent, atomic, identities and all reference is articulable as
applications
of the index space formed by these identities.

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.  Example: normative references, i.e.
links to something that the current object is supposed to conform to, like a
schema.

Attempts to make progress have not been very successful, as in the wars over
'role' in X-Link and the flamewar that was precipitated over "use of relative
URIs in namespace names."

Tim talked at the All Groups Meeting about "Web services" in terms of the
sequence of messages sent.  This is not really the fundamental point.  A
"service-oriented architecture" is about publishing descriptions of potential
transactions  [UDDI <<http://www.uddi.org/>http://www.uddi.org/>].  A service
offering is a pool, of transaction potential, with some constraint information
as to the nature of the transactions that could potentially be transacted
through accessing this 'service.'  A "Topic Map" characterizes a topic by
extension, by indexing a collection of related instances.  A service offering
says nothing about extension, about the identities of the resulting
transactions.  It does provide characterization by intension, by
constraints on
the type and metric properties of transactions resulting from the potential
associated with the service offering.

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.  Demand for
service prefers to be vague about 'which' service is sought and more specific
about 'what' service is sought.  The service seeker does not wish to narrow
the
description of the service sought to the point of eliminating all competition
among service offerors.  URLs reflect this mix of abstraction as to what and
which service is addressed.  Ambiguity is an intrinsic part of the scenario.

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.

This theme is developed further in 

<http://trace.wisc.edu/docs/ud4grid/#_Toc495220392>http://trace.wisc.edu/do
cs/ud4grid/#_Toc495220392

Al

Received on Saturday, 8 December 2001 12:40:38 UTC