- From: Larry Masinter <LMM@acm.org>
- Date: Tue, 1 Jun 2010 13:55:26 -0700
- To: "'Jonathan Rees'" <jar@creativecommons.org>
- Cc: <www-tag@w3.org>
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