Re: BioRDF: URL Statements

Matthias,

These points wrt LS URIs resonate quite well with me...

Continuing on with this reasoning, it would appear the only  
difference URI resolution offers (for pure RDF data only) is getting  
back a set of RDF statements from the URI authority. This does not  
represent all the existing RDF triples on the URI, but only those the  
authority has compiled, curated, versioned, and published.

Since the authority is embedded in the LSID structure, the LSIDS  
offer a hook to finding out "who" has the authoritative curated  
source on this URI, and therefore that a resolvable chunk of RDF does  
exist at that authority. Perhaps just a call to the authority (via a  
special request URL) to check for resolvability (in the LSID case) is  
simply what is needed.

For all the other RDF statements around a URI not owned by any  
authority, we will eventually need the equivalent of a URI-to- 
statement indexing system on the scale of google, but serving a very  
broad life science and medicine community...

-- vendors, any takers ? ; )

see you in a few days...

Eric


> 1) Most URIs on the Semantic Web are symbols for things, e.g. a  
> concept
> or a physical object
>
> 2) Things like concepts and objects cannot be 'resolved' through the
> internet.
>
> 3) What current proposals about the 'resolution' of URIs do is trying
> to force four different things into a single URI:
> a. the symbol for a thing,
> b. the symbol for an information  resource (i.e. a certain ordering of
> bytes, for example a JPEG picture or an HTML document) and
> c. a string (i.e. a URI) that can be used in conjunction with some
> resolution mechanism in order to yield the information resource
>
> 4) Trying to lump ontologically different things into one symbol is  
> bad
> practice, and leads to a lot of confusion. This confusion can be
> avoided by clearly distinguishing  a, b and c in our RDF graph.
>
> 5) Finding additional RDF statements about a given resource has not
> much to do with 'resolution', would more accurately be described as  
> making
> a query. These two things should not be mixed up. SPARQL endpoints are
> probably the best solution by far.
>
>
> //Matthias