Re: scheduling persistent naming discussion

Mapping is essentially a reference relationship. And naming and 
reference is a philosophical problem that no one, as far as I know, can 
solve because there is a fundamental epistemological gulf -- the 
so-called Descartian gap.

For instance, http://dfdf.inesc-id.pt/ex/pinetree// is the name (only in 
the form of a URI) of a tree. But who can be absolutely sure that, when 
two people use the same URI are talking about the same tree? And what is 
a tree anyway -- what does it refer?

If http://dfdf.inesc-id.pt/ex/pinetree is designated a persistent URI, 
what is it that will be persisted?

1. Does it mean that the referenced tree shall persist? That is: never 
change and never die?

2. Does it mean that the reference(mapping) between 
http://dfdf.inesc-id.pt/ex/pinetree and the tree persist? But besides 
the above mentioned epistemological gap, what if the tree is removed or 
died? Does the persistent relationship hold?

3. Does it mean that what is returned from that URI persist? This is 
something that can be done. Hence, what is persisted is the information, 
i.e., what you perceived/received, but not its meaning, i.e., what you 
and I think it references. The former is objective while the latter 
subjective.

4. Does it mean that the URI is always alive in the Web? This can be 
done because persistence is ultimately a service. Technology can help 
but not specifications.

Hence, to second Larry's opinion, "persistent service" makes sense 
because it suggests that a service always serve the same information. 
Dan's "Long-life URI" makes sense too as it suggests that a service 
always serve. Any other attempt to define it, in my mind, will bring 
questions that will bring the question itself into question.

But, who knew ... Maybe that is the purpose of this discussion.

Xiaoshu

On 3/23/10 3:06 PM, Nick Gall wrote:
> Pardon the intrusion, but the discussion reminded me of one of my 
> favorite quotations about names and naming, which I think is relevant 
> in this context:
>
> /A fundamental purpose for a name, then, is to accomplish sharing, and 
> the second scheme is to include a name for a component object in a 
> containing object. When names are used, some way is then needed to 
> associate the names with particular objects. As we shall see, it is 
> common for several names to be associated with the same object, and 
> for one name to be associated with different objects for different 
> purposes. In examining these various possibilities, we shall discover 
> that they all fit into one abstract pattern. This abstract pattern for 
> containment by naming is as follows: a context is a partial mapping 
> from some names into some objects of the system. To employ a component 
> object, a name is chosen for the object, a context that maps that name 
> into that component object is identified or created, the name is 
> included in the containing object, and the context is associated with 
> the containing object. At some later time, when the containing object 
> is the target of some computation, the program interpreter performing 
> the computation may need to refer to the component object. It 
> accomplishes this reference by looking up the name in the associated 
> context. Arranging that a context shall map a name into an object is 
> called binding that name to that object in that context. Using a 
> context to locate an object from a name is called resolving that name 
> in that context./
> /
> /
> JH Saltzer, "Naming and Binding of Objects" 
> http://web.mit.edu/Saltzer/www/publications/nbo/nbo.html
>
> What needs to persist seems to be the mapping, so perhaps "persistent 
> mapping" is the more precise term?
>
> -- Nick
>
> Nick Gall
> Phone: +1.781.608.5871
> Twitter: ironick
> AOL IM: Nicholas Gall
> Yahoo IM: nick_gall_1117
> MSN IM: (same as email)
> Google Talk: (same as email)
> Email: nick.gall AT-SIGN gmail DOT com
> Weblog: http://ironick.typepad.com/ironick/
>
>
> On Tue, Mar 23, 2010 at 1:25 PM, Jonathan Rees 
> <jar@creativecommons.org <mailto:jar@creativecommons.org>> wrote:
>
>     On Tue, Mar 23, 2010 at 10:37 AM, Larry Masinter <LMM@acm.org
>     <mailto:LMM@acm.org>> wrote:
>     > ===================================================
>     > I met a traveller from an antique land
>     > Who said: Two vast and trunkless legs of stone
>     > Stand in the desert. Near them, on the sand,
>     > Half sunk, a shattered visage lies, whose frown
>     > And wrinkled lip, and sneer of cold command
>     > Tell that its sculptor well those passions read
>     > Which yet survive, stamped on these lifeless things,
>     > The hand that mocked them and the heart that fed.
>     > And on the pedestal these words appear:
>     > "My name is Ozymandias, king of kings:
>     > Look on my works, ye Mighty, and despair!"
>     > And Here is my URL, http://ozymandias.org.
>     > Nothing beside remains. Round the decay
>     > Of that colossal wreck, boundless and bare
>     > The lone and level sands stretch far away.
>     > ================================================
>     >
>     > A "name" is just a string. What you really want is not a
>     "persistent name" but a "guarantee" -- whatever that might mean --
>     of a service, generally recognized by society -- that will direct
>     others from the name to the thing that you want the name to mean.
>     >
>     > As long as we call the problem "persistent naming" rather than
>     "persistent services", we'll keep on talking in circles.
>
>     Yes, many of us made the same point on the GBIF committee I served on,
>     so we talked about "persistent actionable identifiers", although I
>     might have been happier with "persistently actionable identifiers".
>
>     I don't think anyone disagrees with the point that it's not just a
>     technical problem. The sloppy terminology is more a matter of habit
>     and entrenched practice than misconception. The digital archiving
>     world, for example, seems hellbent on "persistent identifier" (without
>     misconception about what is *meant*, I think) and nothing we say will
>     change what it calls this phenomenon.
>
>     Maybe Noah can help make the point by changing it on the agenda to
>     "persistent identifier resolvability" or something of that sort.
>
>     Jonathan
>
>     > I've made the link before, but really urge review of the 1999
>     workshop: (9/99) Problems URIs don't solve
>     (http://larry.masinter.net/9909-twist.pdf) Presentation at  TWIST
>     99( http://www.ics.uci.edu/IRUS/twist/twist99/)  The Workshop on
>     Internet-scale Software Technologies, Internet Scale Naming.
>     >
>     > also
>     http://masinter.blogspot.com/2010/03/resources-are-angels-urls-are-pins.html
>     .
>     >
>     > Larry
>     > -----Original Message-----
>     > From: www-tag-request@w3.org <mailto:www-tag-request@w3.org>
>     [mailto:www-tag-request@w3.org <mailto:www-tag-request@w3.org>] On
>     Behalf Of Jonathan Rees
>     > Sent: Tuesday, March 23, 2010 5:02 AM
>     > To: www-tag@w3.org <mailto:www-tag@w3.org>
>     > Subject: scheduling persistent naming discussion
>     >
>     > It would be unfortunate to discuss ISSUE-50 without Larry, scheduled
>     > for 3pm Thursday after he's gone, since he provides such an
>     important
>     > skeptic's perspective and has been thinking about this problem for
>     > over a decade.
>     >
>     > I don't know how to fix this, though - the only options I see are
>     > swapping with one of the morning sessions, secrets in URIs and
>     content
>     > type override, both of which seem pretty important.
>     >
>     > In his absence we would just have to do our best to represent him.
>     >
>     > So I just throw this out there without any particular request or
>     > advice. Maybe let's bring it up under agenda review on Monday.
>     >
>     > Jonathan
>
>