Re: BioRDF: URL Statements

[Eric Neumann]

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