Re: metadata, resources, and angels & pins

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