RE: BioRDF: URI Best Practices

-- Alan,

> You are right in the sense that if I receive a naked URI in 
> the email I'll have to dereference it to learn something 
> about it. OTOH, this is not the case I am thinking about. I 
> am more concerned with URIs that I find in a SW context - 
> namely part of a graph - a packet of SW information in some 
> message. I expect my ontology to be clear about such things 
> as whether a thing is an information resource or not.

I am not sure what the purpose of such a classification.  But my logic
(perhaps a faulty one) tells me that your proposed solution won't be
generalized to all cases.  If it is true, it is becomes "sort of" a hack
than a "solution", don't you think? 

> >> 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.
> >
> > I would also be cautious about that.  This seems to be 
> similar to what 
> > the web service is doing.  I hope we don't try to reinvent 
> the wheel, 
> > especially it isn't a small wheel to invent by any means.
> 
> Not sure what you mean here. The intention was to provide a 
> mechanism for indirection similar to what is desired by the 
> LSID spec, but explicitly represented in the same way I 
> represent the rest of my SW content, rather than by using 
> another network protocol, like the LSID, DNS,  etc.

Do you mean, provide a vocabulary to map a "URN -> HTTP URI"?  No matter
what, your solution needs a set of RDF statements.  I just don't understand,
how you get the RDF first?

Maybe, I misunderstood you correctly.  Can you give a simple foo-bar
example? And illustrate what advantage it gives?

Xiaoshu

Received on Monday, 24 July 2006 13:08:16 UTC