On Fri, 21 Jul 2006, Alan Ruttenberg wrote:
Nice idea. I've added a similar proposal to the same wiki page[1].
Basically, I would argue that there are three aspects to dereferencing, with
the problem being that there is no one thing that you always want
dereferencing to get you.
1. The kind of information you want to get by dereferencing - You might want
the primary data if it is an information resource. You might want metadata of
various kinds in all cases (definition, policy, history, picture-of). 303
notwithstanding, I'd rather know that I am dealing with a non-information
resource *before* I touch the network.
2. The representation type - I think this is handled by mime types
3. The transport - http etc.
So my proposal suggests a class that defines ways of transforming the URI you
find in a SW document into URLs that get specific types of information. The
fact that a transform to URL is provided means you get the transport (because
it is part of the transformed URL). Different properties of the class let you
retrieve different patterns for different sorts of information (1.). The
representation 2., is not explicitly represented, it should instead be part
of the definitions of the properties. We typically want to know *before* we
dereference, what we would get back.
I would further argue that as much as possible about this should be
represented explicitly in your ontology, as Matthias has suggested.
As Xiaoshu pointed out, content negotiation (specific accept headers
dispatched to a URL) give you *most* of this functionality purely at the
transport level - assuming there are appropriate mime types for the
representation you have in mind for a URL.
So, it would seem more useful for such a class to identify 1) whether a
URI is a resolvable resource and 2) the mime-types it is 'registered' to
respond to - perhaps with some human-readable annotation documenting exactly what
is expected from a particular mime-type. Where there is only one
associated representation for a URL, it is sufficient to simply identify
the URI as a resolvable identifier and for a client to do a GET without
any accept headers (since the lack of any registered mime-types indicates
that the URL only has one representation modality)
I like the idea of guiding the dereferencing process in
a formal way, but I think content negotiation is the better 'hook' for
retrieving various representations of the same URL.
I'll update the Wiki accordingly
Chimezie Ogbuji
Lead Systems Analyst
Thoracic and Cardiovascular Surgery
Cleveland Clinic Foundation
9500 Euclid Avenue/ W26
Cleveland, Ohio 44195
Office: (216)444-8593
[EMAIL PROTECTED]
