Re: Proposal: variables, templates, and Stickey Cyber Molecules

Seth Russell wrote:
> 
> Frank Manola wrote:
> 
> > Seth Russell wrote:
> > >
> > > This is where I think we need to draw a distinction between internal and external.
> > > Most implementations assign a unique identifier to any node they create (anonymous
> > > or not); the question, I think, is whether it is wise to publish that unique
> > > identifier to the outside world as a URI.  I would weigh in on the side that it is
> > > not.
> >
> > It seems to me there are a couple of issues here (on the other hand, I
> > may be misunderstanding what the "universal" in "URI" means).  One is
> > the implication of using the word "publish" in the quotation above.  I
> > may be wrong, but just because you assign a resource a URI doesn't
> > necessarily mean the URI gets (or ought to be)
> > published/widely-distributed.
> 
> Yes, certainly, and that was my point.  How widely it is distributed is not the point,
> anything that is outside of the boundary of the running application would, in my way of
> thinking, be publishing.
> 
> > It's just that the resource is uniquely
> > identified within a universal scope.
> 
> I think your term "universal scope" is mischosen here.  If it is not published to the
> external world (or read from the external world) than the scope of this unique identifier
> is the boundary of the local system; whatever that may be; for example it might be a
> database on a personal computer.   The scope is the internal data of a single running
> application.  This scope cannot be considered "universal".

I think I need to clarify what I meant by "universal scope" then.  We
were discussing whether you could/should assign URIs as internal
identifiers (the original question involved assigning URIs to anonymous
resources).  What I understand by a URI is a string that uniquely
identifies something within a universal scope (here, the whole Web). 
That seems to me to be a characteristic of the way the string is
constructed/assigned and associated by the assigner with a given
resource, and doesn't have anything to do with how widely the URI is
actually disseminated.  This is why I made the comment below about there
being URLs that aren't widely published.  The URLs in that case have
"universal scope" in the sense that they uniquely identify a resource
throughout the whole Web.  However, that doesn't mean that the URLs must
be broadcast to or accessible by that whole scope;  it may just be a
secret between you and me, or internal to a given site.  One
characteristic of using a URI, however, is that if the URI *were*
disseminated more widely, e.g., if I decided to share my internal
information involving the URI with other parties, the URI would still be
a unique identifier as far as those additional parties were concerned,
which would not be the case if I'd used an purely internal identifier of
some kind.  That may or may not be an advantage in a given situation. 
The point is that just because we want to identify something that's
going to be internal doesn't mean we can't use URIs (or conversely, that
just because you use a URI to identify something doesn't mean the URI is
necessarily going to be known outside some particular usage context
you've decided to establish).  

> 
> > There are certainly lots of Web
> > resources whose URLs aren't widely published, or which are only
> > accessible from within a given context (using a loose definition of
> > "context").
> 
> Ok.
> 
> > That's a question of access control rather than unique
> > identity.
> 
> The restriction of access control restrains the uniqueness of the identity to the scope
> of the local system.  It could get a bit philosophical at this point, hopefully we won't
> need to and you will see where I am going;  otherwise we might need to wake up the late
> Willard Van Orman Quine.

I think the scope of uniqueness of identity and the scope within which
that identity is known are separate things, as I tried to explain
above.  

> 
> > So I think your distinction between internal and external (we
> > could even have varying degrees of internalness/externalness) is a good
> > one, but that seems to me distinct from whether you can use URIs for
> > "internal" references or not.
> 
> Well yes I agree.  Internally within our system we must be able to dereference our
> pointers,  therefore we must have unique identifiers.  If I say [:Socretes a :Man] and
> then add later  [:Man :hasProperty :Mortal], the only way I can get from :Socretes to
> :Mortal is via the unique identifier :Man.  But it need only be unique internally to my
> local system .... it's quite a different animal from the URI.

It's true that here you only need internal uniqueness, and you don't
*need* a URI.  But:

a.  that doesn't mean you *couldn't* use a URI (it would certainly be
internally as well as universally unique)
b.  that also doesn't mean that if you *did* use a URI the knowledge of
that identifier would necessarily creep outside your system

> 
> > It's going to have to arise one way or another.  Certainly if we're
> > going to identify things in the world (as opposed to Web pages stored in
> > specific files in computers) using URIs, there really doesn't appear to
> > be any way to keep people (or computers) from using and publishing
> > multiple URIs that turn out to identify the same thing, unless we have a
> > lot of very strict regulation by registration authorities that people
> > don't seem to want.
> 
> I agree, but How?
> 
> Seth Russell

My assumption is that we'll deal with these situations basically the way
people do:  by discovering (or being told about) the fact that specific
different identifiers refer to the same thing and "recording" the
information in an assertion of some kind, like (inventing hurriedly)
:foo :isSameResourceAs :bar, which then gets wider circulation
(attributed to :Frank, whom you may choose not to believe), and
gradually we eliminate the redundancy.  Sorry it's so messy, but it's
messy now, and there are lots of things machines don't really unmess
very much.  

--Frank


Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-8752

Received on Friday, 19 January 2001 17:42:21 UTC