W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > February 2007

RE: [BioRDF] URI Resolution

From: Eric Neumann <eneumann@teranode.com>
Date: Tue, 6 Feb 2007 10:24:53 -0500
Message-ID: <A3970D83EC72E84B8D2C2400CD6F0B9FE9B248@MI8NYCMAIL16.Mi8.com>
To: "Xiaoshu Wang" <wangxiao@musc.edu>
cc: public-semweb-lifesci@w3.org


> This is one of my points. Technically, the discussed problem is a simple
> string substitution, why making it so complicated using an RDF engine
> with a lot altered semantics plus heuristic approach. 

Xiaoshu,

I guess mainly because string-substitution definitions are not standardized on the Web, but ontologies and their inferencing are.

A reference implementation would IMHO help clarify the issues... 

Eric


-----Original Message-----
From: public-semweb-lifesci-request@w3.org on behalf of Xiaoshu Wang
Sent: Tue 2/6/2007 8:59 AM
To: public-semweb-lifesci@w3.org
Cc: public-semweb-lifesci@w3.org
Subject: Re: [BioRDF] URI Resolution
 

Eric Neumann wrote:
> Since much of what is being discussed here is about a "practical time to turn-around" for resolution, this is a quantitative criterion that can be measured.
>
> Why not set up a small demonstration for handling some class of URI's (e.g., list of genes), that have getMethods, and try accessing these as URIs from another client or server? I see even getting by with a demo that does not even use a full-fledged inference system-- simply "look for" PATTERN: /http://foo.com/(.*)/ and re-direct or reply with getMethods...
>   
This is one of my points. Technically, the discussed problem is a simple 
string substitution, why making it so complicated using an RDF engine 
with a lot altered semantics plus heuristic approach.  If the goal is to 
minimize, but not eliminate, 404, why not create a simple registry of 
"moved URI"s.  Hence, once an RDF engine encounters a new URI, try to 
dereference it natively. If failed, then check with registry.  If found 
an entry, follow the new link, else, bad luck.  The implementation would 
be easy and fast since it is just a simple table lookup.

I am not proposing that we actually implement this (I think the persist 
issue is mostly a social issue, so best practice is the best cure), I am 
just trying to illustrate the point that there can be simpler solution 
to achieve the same result. Then why make it so complicated?  We 
shouldn't propose a SW solution to any problem, just because we are SW 
interest group. 

Cheers,

Xiaoshu 
Received on Tuesday, 6 February 2007 15:28:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:00:46 GMT