W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > March 2009

RE: blog: semantic dissonance in uniprot

From: Michel_Dumontier <Michel_Dumontier@carleton.ca>
Date: Wed, 25 Mar 2009 21:46:39 -0400
To: "David Booth" <david@dbooth.org>, "W3C HCLSIG hcls" <public-semweb-lifesci@w3.org>
 I agree that different URIs should be used when trying to denote
different things. Like for instance, we might have different URIs for
different representations (eg html, xhtml, rdf, etc). I know the
NeuroCommons people like to formulate URIs with the representation and
others, like UniProt add a suffix to the ID. I've also shown you a case
where multiple descriptions can exist
(http://ontology.dumontierlab.com/Protein) - so what to do then? Is the
approach I've taken reasonable? It certainly can't conform to the 303
redirection and content negotiation.

Anyways, if the difference between an entity and a representation is
_actually_ what we've been talking about all along - then I think I was
ridiculously confused by the lack of specificity in the preceding email

 If however, what we've been talking about is that identifiers like  

are actually database records, and not molecular entities, then we can
settle this quickly:

Uniprot RDF file: http://www.uniprot.org/uniprot/Q16665.rdf 
(is this what people were referring to as a Record???)


<rdf:Description rdf:about="http://purl.uniprot.org/uniprot/Q16665">
 <rdf:type rdf:resource="http://purl.uniprot.org/core/Protein" />

It's clear that the entity denoted by :Q16665 is rdf:type :Protein and
is the subject of statements that are biological in nature such as being
located in sub-cellular compartments or being involved in biochemical
reactions. It is clearly not a Record. This is generally the case for
nearly all entries in biomolecular databases.



Anxiously waiting see if this clears up things or generates controversy
.. it's hard to predict!

> If nobody ever wants to use the same property to talk about the
> database
> record as was used to talk about the molecule, and nobody ever makes
> assertion that implies that the class of database records is disjoint
> from the class of molecules, then I don't see any harm in using the
> same
> URI to ambiguously denote both.   But if one is trying to design data
> to
> be reusable by others in unforeseen ways, there clearly *is* a risk
> that
> someone will want to make such assertions in conjunction with the
> and if that happens there is a clear harm.  This risk is easy to avoid
> by using separate URIs.
> There *are* trade-offs.  Minting two URIs instead of one *does* add
> some
> complexity, though as I pointed out that additional complexity can be
> mitigated to the point that it is a *very* low cost.  Still, different
> people will weigh these trade-offs differently, and what's best for
> situation may not be best for another, as I indicated in my original
> post.
> Furthermore, even if one does use the same URI to ambiguously denote
> both a database record and a molecule, that is not the end of the
> either.  It is possible (though more difficult) to later separate out
> and relate the different senses of an ambiguous URI, as I have
> described:
> http://dbooth.org/2007/splitting/
> Ambiguity is inescapable, and ambiguity between a thing and a page
> describes that thing is not fundamentally different from other kinds
> ambiguity (except perhaps that we are aware of it in advance and it
> be easily avoided), as explained here:
> http://dbooth.org/2007/splitting/#httpRange-14
> Finally, although it is flattering that you have named this suggestion
> after me, I cannot take credit.  As I pointed out in my original post,
> the suggestion to differentiate between a molecule and the database
> record that describes that molecule originates with the Architecture
> the World Wide Web:
> http://www.w3.org/TR/webarch/#URI-collision
> and best practices for implementing this distinction are described in
> Cool URIs for the Semantic Web:
> http://www.w3.org/TR/cooluris
> David Booth
Received on Thursday, 26 March 2009 01:47:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:20:41 UTC