Re: [BioRDF] URI Resolution

This leads me to think that the main relation we are looking for is
one between an information resource (which may have multiple URI's)
and a *string* that is a URL that will help us to get its
representation. Maybe this is obvious.

The www notion of 'resource' includes things that have different
representations (bits) at different times, and things with operations
other than GET, so while I agree with the goal of being precise about
these things and avoiding content negotiation, we're in the
unfortunate position of being without identifiers for particular
representations (snapshots, versions).

I'm updating my draft to include multiple choices for solutions, with
Alan's ontology as one among several, and will try to capture what
you've said. In your view, how would one find information (or
represent the information needed to find information) about a
non-informationresource such as foaf:name?

On 2/2/07, Matthias Samwald <samwald@gmx.at> wrote:
>
>
>
> > - If the server replies 303 See Other, follow the link in the
>
> > response to get information about resource. [obscure hack but worth
>
> > a try]
>
> > (see http://www.w3.org/2001/tag/issues.html#httpRange-14)
>
>
>
> I guess we should find a diplomatic formulation for that.
>
>
>
>
>
> > - Disadvantage: you need an OWL engine to interpret resolution
>
> > information represented in this way, and not all applications have
>
> > an OWL engine. [so why not get one and link it in?]
>
>
>
> I would prefer a different, much simpler approach to ontology-based URI
> resolution. I would suggest that the relation between an information
> resource and the URL that can be used to retrieve a realisation of this
> information resource is explicitly encoded as a triple, without the
> necessity of inferencing on the client-side. Furthermore, there should be a
> 1:1 mapping between the URL and the data that can be retrieved via a HTTP
> GET (no content negotiation). The URI of the information resource should
> preferably NOT be identical with the URL that can be used to get a
> realisation of it. This way, all of the different entities we are dealing
> with (non-information resource, information resource, URL to get a
> realisation of the information resource) would be cleanly separated. If a
> webserver fails or files are moved to another server, the triples can be
> updated accordingly.
>
>
>
> URI resolution for information resources is very important for any
> application on the Semantic Web, and we need to make it as barrier-free as
> possible. Requiring OWL inference for such a basic task is, in my opinion,
> simply too demanding to find widespread adoption. Furthermore, leaving the
> mapping between URI and URL to the server side frees us from the necessity
> to standardize the resolution ontology proposed by Alan, which would surely
> be an arduous task. In the simplest case, we would only need to standardize
> a single property -- to associate an information resource with a URL.
>
>
>
> Xiaoshu, you probably criticise the need for additional triples, but you
> need to be aware that these additional statements are only made for
> *information resources*, not for all resources in the RDF graph. If you look
> at most of the current biomedical RDF/OWL datasets, information resources
> are only a small fraction of all defined resources.
>
>
>
> -- Matthias Samwald
>
>
>
>

Received on Tuesday, 6 February 2007 19:04:29 UTC