Re: Uniform access to metadata: XRD use case.

Eran Hammer-Lahav wrote:
> The reason why your position on links is pointless is because you are trying to use a framework - a tool - as the end and not the mean. Your entire argument is equal to someone walking over to the guy who invented the first axe and told him it has a critical flaw because by itself, it wasn't very useful to figure out what should be built with it.
>   
No.  What I am asking is very simple: if you have invented a hammer 
(description), tell me how the hammer (the description) differs from the 
axe (the awww:representation) so I will know when to use hammer and when 
axe.  From what I see, your viewpoint would be this: if you use a thing 
to drive a nail (i.e., HTTP Link), call the tool the hammer and if you 
use it to half something (HTTP GET), call it an axe.

Would the above analogy fine?

As you haven't tell me the difference between the hammer and an axe, (if 
so, please do it again because what I now get is only the symbolic 
difference but semantic ones), then I would call them both "tool" (my 
HTTP GET).  Hence, if I want to either drive a nail or half something, I 
will simply use the "tool".  Hence, who is suggesting that Axe or tool 
has a critical flaw.  It is definitely not me as my vocabulary doesn't 
have the word "axe".  Had there been one, it must be a synonym to "tool".

If you do, please tell me the semantic difference first.  If it is so 
clear to you, I bet you can construct something concrete.
> The link framework offers something very simple. If you have two resources, where you have an interest in one, and would like to obtain more information (given a very specific context), you can find this extra information elsewhere. It has nothing to do with conneg. We are talking about two discrete resources. But the key here is that links by themselves don't do much. Applications must specify how certain links are used in certain situations. You are completely ignoring the application layer.
>   
Sure.  RDF is simple too.  a:Resource a:Property(or a:Predicate or a 
link:type) another:Resource.  Again, call me numb but I don't know how 
Link is any different from RDF.  I did not imply anything else, except 
that I cannot see how different the semantics put in Link would be any 
different from an RDF file.

You put the discussion of Conneg way too early now.  What I have asked 
is two but related questions.

The first question is what the above is centered, i.e., the *semantic* 
difference between Description and Representation.  At this time, Conneg 
is not involved. As I cannot tell them apart, I am guessing that, if 
that is the case, the necessity for Link/MGET, must be because there 
exists some reason that a resource cannot serve its 
Description/Representation.  That is what I said: it must come down to 
one of the arguments of either IR and legacy *representation*.  It is 
under the argument of legacy *resource*, that content negotiation comes 
into play.  I dispute the notion of legacy *resource* because a resource 
can always have new *representation*. It is under this context that I 
said that Link is functionally redundant to Conneg.

Of course, I could be wrong.  But don't you think that the following two 
items would be more productive and straight-forward?
(1) A definition of that tells Description from Representation.
(2) A use case that illustrated the necessity of Link w/o either resting 
on the concept of IR, (if you insist, again, give a concrete definition 
of IR that tells it from non-IRs) or due to the limit of a specific 
format. 

Would this be fair?
> Now, if you want to use an axe to insert related information into the resource itself, go ahead. But I strongly believe you are using the wrong tool here (to put it mildly). 
Sigh.  Who is the guilty party?  (See your opening paragraph)
> The endless discussion over links vs. conneg is pointless. I learned not to debate religion when I was 12, and that lesson applies here.
>
> I am not going to use conneg for my use cases because:
>
> 1. It overloads content-type with relation type or worse, an application specific activity.
>   
It is that LINK overloads RDF and HTTP.  All Headers of the HTTP 
requests are, in fact, about parsing of the HTTP entity.  Link, in fact, 
breaks this boundary. 
> 2. It requires minting content types that are limited to representing metadata. A quick look at a typical Windows registry for file types or URI scheme types shows just how broken this approach is.
>   
I am not exactly sure what you are imputing here.  If you are suggesting 
that only one (or a few formats) for every task.  I disagree.  There are 
just too many real-world needs for different format under different 
situations.  For instance, I don't think XML-based format is the ideal 
choice for encoding large-size scientific data.  And many programmers 
have voted with their feet, such as with the development of YAML, JSON 
etc.  If you are talking about the flaws of Windows, I bet they would 
eventually accommodate to popular demands because their goal is to sell 
machines.
> 3. There is no way to find meta-metadata. Given three resources, C describes B and B describes A, how would conneg accomplish that? Mint a content type for a description of a description?
>   
Find any RDF file and tell me which resource is data and which is 
metadata.  I want to remind you, for any rdf:Property, there exists an 
implicit inverse property.  If you can divide an RDF graph in two parts 
-- one data and the other metadata, you would really have answered my 
first question raised above.  I cannot.  It is really beyond my 
intelligence.
> 4. It partially fails the Equal Access Principle in that it is not a simple feature for many small and large providers to support. I can tell you that Yahoo! will not support connect for metadata on any of its high value properties for a wide range of reasons. Also many web clients don't give full access to the Accept header or other conneg features. The community I serve with this work depends heavily on extreme pragmatism.
>   
I don't know what Equal Access Principle go to do with it.  Should I 
expect my cell phone browser gives me the same thing or feel of the one 
on my laptop?  And should I expect my RDF agent to do the same thing as 
my ordinary Web browser?  Besides, it only says that Conneg has not been 
understood and perhaps underused.  It says nothing about the necessity 
or superiority of Link.

Of course, your implication might be: let's totally remove Conneg.  If 
this is true.  This is a totally different issue.  Under this condition, 
i.e., without Conneg, Link/MGET is necessary.
> 5. It doesn't allow for an easy one resource-many descriptors link type (you can return a 300 but that isn't really widely used or understood).
>   
You mean that in RDF, I cannot say that?
> And all of this completely ignores the basic principle that data and metadata are not always just different representations of the same resource.
>   
Basic Principle? On which semantic or architectural foundation?
> So I'll use links and you use conneg and meet again in 5 years and see who is getting more traction. Any further debate on this is a waste of time.
>   
Sure.

Xiaoshu
> EHL
>
>
>
>
>   
>> -----Original Message-----
>> From: Xiaoshu Wang [mailto:wangxiao@musc.edu]
>> Sent: Tuesday, February 24, 2009 4:00 PM
>> To: Eran Hammer-Lahav
>> Cc: Julian Reschke; Patrick.Stickler@nokia.com;
>> jar@creativecommons.org; connolly@w3.org; www-tag@w3.org
>> Subject: Re: Uniform access to metadata: XRD use case.
>>
>> The critical flaw of all the proposed approach is that the definition
>> of
>> "metadata/descriptor" is ambiguous and hence useless in practice.  Take
>> the "describedBy" relations for example.  Here I quote from Eran's
>> link.
>>
>>       The relationship A "describedby" B asserts that resource B
>>       provides a description of resource A. There are no constraints on
>>       the format or representation of either A or B, neither are there
>>       any further constraints on either resource.
>>
>> As a URI owner, I don't know what kind of stuff that I should put in A
>> or B.  As a URI client, how should I know when should I get A and when
>> B?  Since I don't know what I might be missing from either A or B, it
>> seems to suggest that I must always get both A and B. Thus, I cannot
>> help but wondering why they are not put together at A at the first
>> place.
>>
>> The same goes for MGET, how a user knows when to GET and when to MGET?
>> PROFOUND is different because when people use it, they have already
>> known that the resources is defined by WebDAV.   Hence, these kind of
>> ideas only works when the client already have some knowledge about A.
>> But, to propose it as a general framework for the Web, it won't work.
>> At the most fundamental level, we only know three things about the Web
>> -- URI, Representation, Resource.  The concept of metadata is
>> ill-conceived at this level because as data about data, to say metadata
>> implies that we already know something about the resource we tries to
>> access, a piece of knowledge that we don't have.
>>
>> There are a lot of implicit assumptions under the so-called "uniform
>> access to metadata/descriptor" approach.  It either requires the
>> definition of IR or a one-on-one relationship between Resource and
>> Representation.  As the former implies that non-IR cannot have a
>> representation, it makes the "descriptor/metadata" necessary.  The
>> knock
>> on this assumption is that the definition of IR is impossible to work
>> with.
>>
>> The 1-on-1 relationship gives rise to the so-called "legacy resource".
>> But the word "legacy resource" is wrongly named too.  In the Web, there
>> might be something as "legacy representation" but there should NOT be
>> such thing as "legacy resource" because the latter implies that the
>> Resource is closed and no more semantics will be added.
>>
>> But the so-called "metadata/descriptor" problems can be solved by using
>> HTTP Content Negotiation, making any other proposal a redundant one.
>> The
>> actual issue, as I have discussed in [1], is about the incomplete
>> syntax
>> of the URI specs, which  currently does not have a syntactic notation
>> the other two foundation objects in the Web, i.e., URI and
>> Representation.  Once we supplement URI spec with those syntactic
>> sugar,
>> such as the one I proposed in [2], then, we can have a uniform approach
>> to (1) describe URI along with standard resources and (2) to
>> systematically discover the possible representation types, i.e.,
>> Content-Type/MIME types, associated with a Resource (either URI or
>> standard Resource). As a particular content-type is equivalent of a
>> particular *service*, hence, the approach in effect establishes a
>> uniformed approach to service discovery.
>>
>> What is required is to define Content-Type in URI.  Once we have these,
>> not only Data/Resource are linked but DataType/Service.  The best of
>> all, it works within the conceptualizations defined in AWWW, and does
>> not require any other ambiguous conceptualization, such as, IR,
>> metadata, and description, etc.
>>
>> 1. http://dfdf.inesc-id.pt/misc/man/http.html
>> 2. http://dfdf.inesc-id.pt/tr/uri-issues
>>
>> Xiaoshu
>>
>> Eran Hammer-Lahav wrote:
>>     
>>> Both of which are included in my analysis [1] for the discovery
>>>       
>> proposal.
>>     
>>> EHL
>>>
>>> [1] http://tools.ietf.org/html/draft-hammer-discovery-02#appendix-B.2
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: Julian Reschke [mailto:julian.reschke@gmx.de]
>>>> Sent: Tuesday, February 24, 2009 1:45 AM
>>>> To: Patrick.Stickler@nokia.com
>>>> Cc: Eran Hammer-Lahav; jar@creativecommons.org; connolly@w3.org;
>>>>         
>> www-
>>     
>>>> tag@w3.org
>>>> Subject: Re: Uniform access to metadata: XRD use case.
>>>>
>>>> Patrick.Stickler@nokia.com wrote:
>>>>
>>>>         
>>>>> ...
>>>>> Agents which want to deal with authoritative metadata use
>>>>>
>>>>>           
>>>> MGET/MPUT/etc.
>>>>
>>>>         
>>>>> ...
>>>>>
>>>>>           
>>>> Same with PROPFIND and PROPPATCH, btw.
>>>>
>>>> BR, Julian
>>>>
>>>>         
>>>       
>
>

Received on Sunday, 1 March 2009 23:53:02 UTC