RE: BioRDF: URI Best Practices

Matthias,

> The motivation for my proposal was that I think it is better 
> to know which URIs are supposed to be resolvable before we 
> are actually trying a HTTP GET or try to resolve something 
> with the LSID system. In large datasets we have plenty of 
> URIs -- if every agent would try to GET/resolve every URI 
> that would pose quite a burden on the whole system 
> (especially in the case of LSID).

Of course! So the issues is what we should consider a metadata (not THE
metadata) and data because pragmatically, we all want to obtain some
metadata before getting to the data.  This is my orignal support for the
LSID because there is the getMetadata() method in addition to getData(). But
the http-range-14 issue solves the problem.  If we follow a pragmatic
definition that metadata about a resource is in RDF and data is otherwise.
We could use the HTTP's content negotiation, i.e., to request a
application/rdf+xml MIME type, to obtain the metadata about a resource
identified by a HTTP-URI.
 
> I should have been clearer, sorry. I was not talking about 
> the metadata in an arbitrary context -- I was talking about 
> the metadata we get back when we resolve the URI through a 
> given mechanism.

Unless the metadata returned back is non-RDF, otherwise, you cannot escape
the problem.  Just as I said in the example, even if it returns the same
assertion everytime.  But if you ever used a vocabulary outside of your
control, you cannot make claim of the immutability of the metadata.  But if
we don't share ontology, then there is no point to use SW. 

> But in either case, the problem
> > contradicts itself because: how how can someone and somehow 
> get a hold 
> > of a description in your proposed ontology at the first place?
> 
> Well, it could be part of the ontology the user/agent is 
> already posessing. It could also be part of the metadata 
> yielded by a resolution process. Its not harder or easier 
> than getting a hold of any kind of RDF triples. You start 
> with something and try to go further.
 
Then wouldn't you have to know that about any URI out there at first hand
because you can get back RDF statements described in any URIs? First, it is
not possible.  Second, if so, it becomes a closed world, wouldn't it?  
 
> > But just as Godel's incomplete
> > therom has told us: don't try to use the same technology to 
> define the 
> > foundation of the technology.  Doing so will only get more 
> questions 
> > than answers.
> 
> As someone who has already invested some brain power in 
> researching the brain, these sentences seem very discouraging to me ;)

:-).  I was a neuroscience major too but find this encouraging.  A wise man
is not a man who knows a lot of things but a man who knows his limit.  Godel
told us not to waste time on certain things.


About LSID and HTTP URI, my position is not trying to say which URI scheme
is superior or inferior.  As an identifier, there is nothing wrong with
either one.  Just as we cannot say whether John is a better name than Joe,
or vice versa. My support for using HTTP URI is because it has better
support for the "prefered" network protocol. Had LSID been popular when the
web was first started, my position would have just reversed.  Currently, I
did not see any mechanisms that LSID proposed cannot be adequately addressed
with HTTP.  Then I wonder why we spend extra time/resource to adopt a new
one?  In fact, I have not seen anyone who has written their ontology in LSID
yet.  Isn't the conceptual entity that is supposed to be best named with
LSID or other URI scheme of similar essense? Why is that? Isn't it because
that we all want our resources be easily accessible?  If so, why has other
biological entity to be different?

Cheers,

Xiaoshu

Received on Thursday, 20 July 2006 18:55:39 UTC