- From: Jonathan Rees <jar@creativecommons.org>
- Date: Mon, 21 Feb 2011 14:24:38 -0500
- To: Larry Masinter <masinter@adobe.com>
- Cc: David Booth <david@dbooth.org>, "www-tag@w3.org" <www-tag@w3.org>
OK, I think I see what you are doing now. I don't know how to assign responsibility for my misreading, however, to me or to what you wrote. But let me say: > 0. Resource comes into being > 1. Someone (Party A) makes up ("mints") a URI to identify the resource > (This 'someone' doesn't have to be an 'owner' or have any relationship to the resource) I was misled by 'makes up ("mints")' into thinking that by Party A you meant by what David called the 'URI owner'. By what you said later I think you mean "chooses or mints", meaning A is happy in some cases to pick a URI that s/he got elsewhere. The 'minting' or first occurrence would have been by Z, with Z=A an option. 'URI owner' comes up as part of a collision avoidance convention, which may be irrelevant to your purposes but is important for all the territory David wants to cover. > 2. Party A then communicates this URI to party B ('uses the URI in a statement') > 3. Party B reads the statement and attempts to 'resolve' the URI [determine/ > contact/interact with] the resource So, my A/B/C are your Z/A/B. It is the 'contact/interact with' part that made me think you were talking contactable or interactable resources only. I didn't know what you meant by 'resolve' or 'determine' or that the '/' meant 'or'. I think I get it now. 'Ownership' is probably misunderstood because it is poorly named and articulated. I would have used the word 'authority' emphasizing that in every case it is limited to certain kinds of statements or operations. I'm interested in how your account of URI 'ownership', collision avoidance, and resolution differs from the webarch one, as mine does too. Probably a topic for a different thread though... On Mon, Feb 21, 2011 at 11:15 AM, Larry Masinter <masinter@adobe.com> wrote: > I had A -> B and you've added another link A -> B -> C, but it's a graph (a DAG) > of communication, which includes A -> B, C, D, E, ... (broadcast), > > A-> B -> C -> D -> E > > but I convinced myself that those more complicated stories are built up > one link at a time. > > If A -> B and A -> C, then A, B and C should share some agreement that > B and C understood the "same" thing, and would have some common idea > of what "same" meant, and that A's choice of URI (scheme, path, longevity > of services involved in maintaining the mapping between URI and resource) > would be essential to the reliability of the communication. > > In this case, no message passes between B and C, yet they share > a common understanding. > > How reliable would corporate financial data be, if everyone going to > get the annual report got a different one? If the auditors get a different > set of "books" than the stock analysts, for example? If politicians > could publish different statements about their platform depending on > the politics of who was reading? Yes. I'm sure this will all happen in the coming decades. We already have targeted advertising, yes? > Part of the trust relationship is not just the provenance and reliability > of the communication between the two parties involved in an instance > but also the uniformity. > >> In your account you need a disclaimer that by 'resource' you mean >> 'network resource' or 'resolvable resource'. > > I don't think I need such a disclaimer or intended that there be one. > "tdb" is clearly an example of method for identifying other kinds > of resources, so > >> I'm confident that sense of the word is different from what >> you mean here by 'resource' (although 'determine' makes me wonder). > > I don't know why you're confident I meant the narrower interpretation. > >> I think it's important to recognize that in David's account 'URI >> owner' and 'resource owner' are orthogonal > > I recognize that he meant that; in fact, it is the entire concept > of "owner" that bothers me and I was working hard to avoid. > > "Brought to you by the letter A and the number 3" is funny because > there is no "owner" for the letter A or the number 3 (unless > you think the Unicode consortium is the 'owner' of letters?) The question is, supposing the meaning of the letter A had to change, who would you go to in order to bring that about? If you wanted to change the meaning of the http: URI scheme, you'd go to IETF (and subsequently to everyone who would be affected by your change). If you wanted to change responses to GET http://example.net/x, you would talk (first) to the 'owner' of the 'example.net' domain, and maybe that would be enough. You could in theory change 'A' but you'd need to talk to all users of the Latin alphabet, and have more influence than anyone on earth has. That is, 'A' is owned by its users, even more so than http: or 'Content-language: fr'. I don't know whether this is a distortion of the word 'owner', or vacuous, or what, but I think it's what AWWW and David's article mean to say. Jonathan > Larry > -- > http://larry.masinter.net > > -----Original Message----- > From: Jonathan Rees [mailto:jar@creativecommons.org] > Sent: Monday, February 21, 2011 6:45 AM > To: Larry Masinter > Cc: David Booth; www-tag@w3.org > Subject: Re: "tdb" and "duri" URI schemes... > > On Fri, Feb 18, 2011 at 6:55 PM, Larry Masinter <masinter@adobe.com> wrote: > >> I would write the lifecycle as: >> >> 0. Resource comes into being >> 1. Someone (Party A) makes up ("mints") a URI to identify the resource >> (This 'someone' doesn't have to be an 'owner' or have any relationship to the resource) >> 2. Party A then communicates this URI to party B ('uses the URI in a statement') >> 3. Party B reads the statement and attempts to 'resolve' the URI [determine/ >> contact/interact with] the resource > > This is good, but I think a better version of the lifecycle (one that > reflects better the reality) has an additional step: > > 0. Resource comes into being > 1. Someone (Party A) makes up ("mints") a URI to identify the resource > (This 'someone' doesn't have to be an 'owner' [of the resource] or > have any relationship to the resource) > 2. Party A then communicates this URI to party B ('uses the URI in a statement') > 3. Party B communicates this URI (in a second statement) to party C > 4. Party C reads the 2nd statement and attempts to 'resolve' the URI > [determine/ > contact/interact with the resource] > > That is, a 'definition' of a URI can be used by two non-defining > agents in meaningful communication. The dictionary writer enables two > agents in possession of the dictionary to communicate. > > For example, A might be an agent 'minting' an http: URI for a > document, who communicates the URI to B by transmitting email to B > containing the URI. Then B puts the URI in a document s/he controls, > which C reads, and C tries to resolve it. > > The point being that once B knows the URI, B can 'introduce' the > resource to C using that URI. (The 'Granovetter diagram.') C and A > needn't precoordinate any more than randomly selected pairs of agents. > If there are only two agents, there is only bilateral communication, > and much of the richness of the Internet/Web - standards, registries, > DNS, etc. - isn't needed. > > In your account you need a disclaimer that by 'resource' you mean > 'network resource' or 'resolvable resource'. RFC 3986 and RDF both > permit 'resources' that you can't interact with, such as the earth's > core, and I'm confident that sense of the word is different from what > you mean here by 'resource' (although 'determine' makes me wonder). > This is a simple terminological spat that can be cleared up with a > definition or citation to a definition. > > I think it's important to recognize that in David's account 'URI > owner' and 'resource owner' are orthogonal. *If* I were to convince > you that http://example/magnacarta is a URI 'identifying' the Magna > Carta, this may be because I exercised 'ownership' over that URI > (perhaps I own the domain). That doesn't mean that I own the Magna > Carta. Whether we want to talk in this way is a separate matter; but > it is a self-consistent way to talk. > > Jonathan >
Received on Monday, 21 February 2011 19:30:15 UTC