Re: Uniform access to descriptions

Harry Halpin wrote:
> Xiaoshu Wang wrote:
>   
>> Harry Halpin wrote:
>> <snip>
>>     
>>> Sigh. Look, in some cases content negotiation for RDF is not going to
>>> work. Resources can be linked to each other to provide descriptions and
>>> authoritative meta data. Linking is very powerful. Most people know what
>>> links are. Most people have no idea that content negotiation even
>>> exists.
>>>   
>>>       
>> Are you talking about HTTP LINK: header or HTML <link>.  The latter is
>> fine.  What I mean the former is useless.
>>     
>>>> What is the purpose of Link then? To make a client to read something
>>>> and then figuring out where the metadata is? Then, putting the Link in
>>>> the content is sufficient.
>>>>     
>>>>         
>>> Yep, and I might add Yahoo! and others are already moving to supporting
>>> this way of adding metadata [1]. I think it's generally a good idea to
>>> standardize things that the majority of the Web is moving to.  And in
>>> some cases the Link cannot be put directly in the content, and in some
>>> cases it can. Please read the GRDDL use-cases [2].
>>>   
>>>       
>> Both [1] and [2] are HTML <link>, which is fine and necessary.  But
>> not HTTP LINK.
>>     
>>>> Either way, it makes the use of Link redundant .  Of course, unless we
>>>> want to abandon content-negotiation, which I don't think we should.
>>>> Otherwise, Link is unnecessary.
>>>>     
>>>>         
>>> Content negotiation is always an option, but it's one many people don't
>>> have access to, because they are in a managed IT environment. How about
>>> giving people *more* options for adding metadata to their page, instead
>>> of *less*?
>>>   
>>>       
>> Content negotiation is an option or less used feature because previous
>> to semantic web, there is no need to.  If this issue of "Uniform
>> access to descriptions" is about to standardize HTML or XML, that is
>> O.K.  But the same rational cannot be applied to HTTP.  If people
>> don't have access to configure content negotiation, s/he won't have
>> access to modify his HTTP LINK header either.  Again, I might have
>> misunderstood what is arguing about here. But if it is intend to add
>> LINK header for an HTTP content, my opinion is - no, don't do it.
>>     
> Glad you agree on the use of "link" in the document itself.
>
> We are thinking that there are cases where people cannot modify content
> and still want to HTTP GET the URI of the document the metadata is
> *about* (since the Link is to metadata "about" a particular URI). Again,
> the use-case in POWDER in particular details this.  The GRDDL use-case
> allows us to connect documents to RDF transforms without using it. If
> you disagree with these use-cases, that's fine, but you're use-cases and
> what you think are useless are different than some other equally valid
> users. Also
>
> I have not seen you give an argument about how the use of a "Link"
> breaks *anything* much less HTTP. In fact, Link was part of an earlier
> HTTP RFC 2068, and was apparently left out as an editorial oversight.
>   
There are a few issues here.  Of course, adding things don't break 
things.  It never does.  But it steers you away from standardization.  
What we would eventually want people to do is to just take one of the 
few methods and get what they want.  Not by infinitely extending a 
protocol.  Hence, proposing LINK, in fact, contradict what the title of 
this discussion does - which is the "Uniform access".  I guarantee you 
if we grant this exception, there will be other similar request for 
making LINK2, LINK3, etc.

I have argued earlier, if people know what kind of LINK they want, it 
means they also know what kind of content type they want.  Using content 
negotiation is cheaper because it takes one round trip but not two.

Second, the semantics of LINK is in fact incorrect.  I dislike the 
general use of the word metadata.  HTTP headers are the "metadata" about 
the message payload - NOT the "metadata" of resource.  (Of course, this 
leads to my different viewpoint of what a URI identifies.)  Hence, 
whatever is in the LINK should be, as all other HTTP headers, about how 
to parse the payload and nothing-else. Using HTTP LINK for the metadata 
of the resource that the URI identifies, in fact, breaks the web's 
founding principle that tis the orthogonality of protocol.  Which makes 
the HTTP LINK an even worse offense.
> Here is the use-case as attached below. Note that we do not specify URIs
> for the XML documents, therefore rending the argument to "just use
> conneg" void
>
> >From GRDDL Use-Case document (I think Ian Davis wrote this part..):
>
> "Oceanic is part of a consortium of airlines that have a group
> arrangement for the shared supply and use of aircraft spares. The
> availability and nature of parts at any location are described by
> AirPartML, an internationally-agreed XML dialect constrained by a series
> of detailed XML Schema. Each member of the consortium publishes the
> availability of their spares on the web using AirPartML. These
> descriptions can subsequently be searched and retrieved by other
> consortium members when seeking parts for maintenance. The protocol for
> use of the descriptions requires invalid documents to be rejected.
> Oceanic wishes to also publish RDF descriptions of their parts and would
> prefer to reuse the AirPartML documents which are produced by systems
> that have undergone exhaustive testing for correctness. There is no
> provision in the existing schemas for extension elements and changing
> the schemas to accommodate RDF would require an extended international
> standardisation effort, likely to take many years. This means they
> cannot alter their XML documents to use GRDDL. Using the ability of HTTP
> Header Linking Draft to specify Link and Profiles for GRDDL
> transformation in HTTP Headers, Oceanic Consortium can serve RDF via
> GRDDL without altering their XML documents. "
>   
Do you think that is a valid use case for a healthy argument? Your 
opinion is already decided by making XML spec non-modifiable and by 
pre-determining "using the ability of HTTP Header Linking *draft*".  
Wouldn't it be better to say: "using the *existing* ability of HTTP 
content negotiation ..."? Which way is better? Using currently spec or 
extending it for something that it can already do?

Content negotiation, in fact, don't need you to use RDF or etc.  If 
their community are bound to do something uniformly, they can design 
their own mime-type to do any profile etc.

Xiaoshu

Received on Monday, 24 March 2008 23:56:22 UTC