RE: larry's position on URIs as names

I don't accept the premise of your question as feasible or
meaningful.


Ambiguity is intrinsic. "What an instance of the protocol 
element is supposed to name" is never unambiguous.

> Suppose a friend of yours is designing a new protocol, and a protocol
> element is needed to designate metadata subjects (e.g. things that
> have titles, authors, etc.). 

That someone thinks they might want such a protocol element
doesn't mean that it is a requirement. 

The desire to "designate metadata subjects" doesn't fall from
the sky. If I don't know what the metadata subject is, if
I have no way of identifying it, then why would I want to
assert some metadata about it?

In XMP, metadata is embedded in digital objects such that
the metadata subject is clear -- it's the object in which
the metadata is inserted.


> Suppose that the documentation and use of
> the protocol leads everyone involved to be clear, to the extent
> necessary for what is communicated in the protocol (the "context"),
> what these subjects are, i.e. what an instance of the protocol element
> is supposed to name. That is, we set up the problem so that ambiguity
> and "meaning" are not issues.

This is the premise I can't accept. "Suppose the problem is solved,
then what is the solution to the problem?" The problem here is that
ambiguity and "meaning" *are* issues.  

Identifiers, in my view, are tokens exchanged in communication based
on a mutual understanding of how to connect the token to a resource
in some way.  "Resources" don't really exist except as they are 
identified. So the idea that you would know what resource might
be without having a way of identifying it or knowing how you might
access it -- well, I don't accept that premise. 

> Also I'd like to remove durability as an issue for the moment. We can
> get back to it after we deal with the other issues.

OK

> Your friend is about to choose http: URIs for that protocol element.
> You care about this person and want them to succeed. Your reaction is:

> 1. No, don't do that!  http: URIs are only for the HTTP protocol, not
> for your new protocol. Use a more suitable URI scheme, or don't use
> URIs at all.

URIs are strings used to identify resources. You should only use
http: URIs for resources that can be accessed via URIs.

Now, with "tdb", or things like it, you can add a level of indirection.

(person-whose-homepage-is http://larry.masinter.net ) isa 
( http://www.merriam-webster.com/dictionary/curmudgeon )


> 2. Fine, do it, but only if what a URI names according to the new
> protocol is the same as what the URI names according to the HTTP
> protocol.

This confuses me, since protocols and URI naming don't have
much to do with each other. And deciding whether what one
URI "names" is the "same as" another is hard.

> 3. Fine, do it, just make sure that what you GET (POST, etc.) at that
> URI via the HTTP protocol is related somehow to what the URI names
> according to the new protocol.

I think "somehow related" is too vague. I think SW generally
uses "is described by" as the relationship.

> 4. Fine, do it, they're different protocols so there is no reason to
> think the two uses either reinforce or interfere with one another
> (like the function and variable namespaces in Common Lisp).

bad hack should not be propagated.

> By "what a URI names according to the HTTP protocol" I mean what it
> names (a file, script, query, service, etc.) according to whoever set
> up the server - but I think it doesn't matter what theory you have of
> http: naming, the choices above are still meaningful - so you fill in
> the blank. If you think http: URIs don't name at all, or that the idea
> is silly, fine, just rule out option 2.

Well, I don't think it's silly, it just makes some presumptions
that I don't accept.

> If your answer is #1 I'd ask what advice between 2-3-4 you give if
> this friend (who maybe is no longer a friend) insists on using http:
> URIs.

I think I gave some guidance on how to do #3: the 'somehow related'
isn't good enough, but 'related by an explicit process which is
part of the metadata protocol' isn't bad.

Received on Tuesday, 1 June 2010 20:56:06 UTC