- From: Xiaoshu Wang <wangxiao@musc.edu>
- Date: Mon, 22 Jun 2009 10:56:44 -0400
- To: Larry Masinter <masinter@adobe.com>
- CC: www-tag <www-tag@w3.org>
Larry Masinter wrote: > My tongue-in-cheek reference to "angels dancing on the head of a pin" confused a few and likely annoyed many; I'm sorry for not indicating humor or a reference, e.g., > http://en.wikipedia.org/wiki/How_many_angels_can_stand_on_the_head_of_a_pin%3F > > >> The most fundamental concepts of the Web are URI, Resource, Representation. >> Hence, none of these -- meta-URI, meta-Resource, or meta-Representation >> -- makes any sense. >> > > I don't think we use those terms, so I suppose the fact that they aren't defined isn't too harmful. And I'm not sure those are the "most" salient concepts needed to discuss metadata meaningfully. > Of course we don't because they do not make sense. And that is my point. "Metadata" whatever it is, must be either be a URI, a Representation, or a Resource. Proposing anything else implies a fundamentally different web architecture than what we know. > I think I have a concept of "metadata" that is worth developing but I need to work on the articulation of it, but here's a shot: > > I think of "metadata" as assertions about a resource; resources are, of course, usually identified by a URI, although in some cases you have a representation "in hand" as well as the metadata about it. > Assertions are not "facts" but rather "opinions" (an assertion by an agent of the agent's belief of facts.) > Well, first, RDF is about assertions. Yes, the second one can make some sense, that is, "you have a representation in hand as well as metadata". But representation is inherently different from resource, in that it is a structure. Then, if I know the structure that I intends, then it makes sense to get its metadata. But, one URI denote one resource, which in turn have multiple representations. Then, if we want to define a generic way to getting the metadata of a *representation*, which one we are talking about? I have mentioned a few times in this list, you can only use content negotiation to make any pragmatic sense. Facts and opinion's are not that much different. They only differ in the scope, in which the assertions is taking to be true. > For metadata access, one agent, with a resource identified by a URI or with a representation in hand, needs to discover (an)other agent(s) and to access the metadata (the other agent's opinions about the resource/representation.) > See above. One resource does NOT have one, but have multiple representation. > In this model, "trust" by one agent of another is the measure the association of belief: my browser trusts your server to the extent that the browser believes assertions made by your server. And access to metadata on the web then is a matter of finding a trustworthy source of metadata for resources, and establishing conventions where trust can be delegated, e.g., a "link" header is an assertion by a HTTP server that another agent is a reliable authority of metadata for the resources provided by the first. > Within the context of an HTTP message, it makes sense to say Headers are the "metadata" of the "entity" because the sole purpose of knowing the headers is for the correct parsing of the "entity". To get the "metadata" for a "resource" makes no sense at all. First, as a URI owner, how do I know what kind of content that I should put in the "entity" and which part the "metadata". Second, for a client, how do I know which content that I will be interested? Think how we are going to implement a browser, if we take any of these so-called "uniform-access to metadata". Should the browser parse both the HTTP "entity" and the "metadata" and present to its client? Or choose a single one? If so, how? If not, then what is the point of the "metadata"? > This is still a little sloppy, but I hope it gives an indication of the direction I'd like to go in metadata access discussions, and the hope that it will be rewarding and not worthy of Xiaoshu's pessimism. > I am not pessimistic by nature. I am just the opposite. And I am pragmatic too. I have opposed any kind of uniform access to metadata approach because it provide no benefit whatsoever. Honestly, take what the LINK proposal and see if there is any difference between it and an RDF doc? The terminology might be different but they are the same triple model. What is implied from this is that: all the so-called metadata approach assumes: there is an objective criteria with whhich we can split an RDF graph in two parts, one "data" part and the other "meta" part. I challenge anyone to establish that definition. If not, then we know what is the fallacy of the so-called "uniform approach to access metadata". The more meaningful and pragmatic way is, as I write in another manuscript, to complete the URI syntax so that we can (1) give URI itself a syntax. (2) to discover all potential representations, i.e., media-type associated with a resource, (3) to denote a representation. This will make URI's referential range *syntactically* complete with regard to the three fundamental concepts of the Web -- URI, resource, representation. Then, given a URI, we can find out what kind of services (service and format are semantically equivalent at the most fundamental level) that a resource supports. Each specific kind of "metadata discovery" can be defined as a special MIME-type (which I also think need to be URIzed). Then, the client subsequently negotiate over that content type to get what they want. This is the only way that makes sense and pragmatic. I don't see any other ways. Xiaoshu
Received on Monday, 22 June 2009 14:57:39 UTC