Re: FRBR WEMI and identifiers

If RDF/linked data really DOES require that servers receive fragment 
identifiers and determine request disposition based upon them, it would 
be a big problem, since that conflicts with the operant RFC's for URI's 
and for the HTTP protocol; and (consequently) with the behavior of 
many/most user agents, servers, and middle ware components.

I'm hoping it doesn't, and that Alex's opinion isn't shared widely in 
the RDF/linked data community.

Jonathan

Brian Stamper wrote:
> And since you cited wikipedia (cringe), might as well use that:
> http://en.wikipedia.org/wiki/Fragment_identifier#Processing
> "The fragment identifier functions differently than the rest of the URI:  
> namely, its processing is exclusively client-side with no participation  
>  from the server."
>
>
>
> On Thu, 12 Nov 2009 17:03:26 -0500, Jonathan Rochkind <rochkind_at_jhu.edu>  
> wrote:
>
>   
>> I'm afraid I can find a buncha RFC's that disagree with you, Alex.
>>
>> In general, clients do not send the fragment identifier to the server.    
>> And several RFC's say they shouldn't. Some even say they aren't part of  
>> a URI at all, although I realize that RDF treats them as such.
>>
>> I guess the conclusion is just: Yes, this stuff is awfully confusing.
>>
>> Alexander Johannesen wrote:
>>     
>>> On Fri, Nov 13, 2009 at 02:37, Ross Singer <rossfsinger_at_gmail.com>  
>>> wrote:
>>>
>>>       
>>>> For the record, I am not agreeing with Alexander:  the fragment should
>>>> never be considered by the server and has nothing to do with conneg --
>>>>
>>>>         
>>> Your understanding of the fragment identifier is deeply flawed, I'm
>>> afraid. Of *course* the fragment should be considered by the server;
>>> that's the point. The server then decides what to do with the extra
>>> identifier, and in the case of HTML it does nothing different, but in
>>> the case of XML and RDF (and friends) they are *different* resources.
>>>
>>> A quick start;
>>>    http://en.wikipedia.org/wiki/Fragment_identifier
>>>
>>>
>>>       
>>>> I was just pointing out that a very major http agent (or, more
>>>> correctly, the library that many http clients are based on) behaves
>>>> incorrectly here.
>>>>
>>>>         
>>> No, I'm afraid *you* do. :)
>>>
>>>
>>>       
>>>> What I'm saying is "don't assume your server will never see fragments".
>>>>
>>>>         
>>> You should be saying, "assume your server always see fragments."
>>>
>>>
>>>       
>>>> It's an aside to the otherwise valid counter argument Jonathan makes
>>>> to Alexander.
>>>>
>>>>         
>>> It's worse than that. From that very same page ;
>>>
>>> "In RDF vocabularies, such as RDFS, OWL, or SKOS, fragment identifiers
>>> are used to identify resources in the same XML Namespace, but are not
>>> necessarily corresponding to a specific part of a document. For
>>> example http://www.w3.org/2004/02/skos/core#broader identifies the
>>> concept "broader" in SKOS Core vocabulary, but it does not refer to a
>>> specific part of the resource identified by
>>> http://www.w3.org/2004/02/skos/core, a complete RDF file in which
>>> semantics of this specific concept is declared, along with other
>>> concepts in the same vocabulary."
>>>
>>> This is an explanation of a big misconception of how the fragments are
>>> meant to work. The only reason for this confusion (I suspect) is that
>>> with HTML-based content-types (which taught us all how "the web
>>> works") the servers don't react to it (creating the illusion that
>>> fragments "do nothing on the server side").
>>>
>>>
>>> Regards,
>>>
>>> Alex
>>>
>>>       
>
>