W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > June 2011

Re: My task from last week: Semantic free identifiers

From: Pat Hayes <phayes@ihmc.us>
Date: Mon, 20 Jun 2011 20:18:18 -0500
Cc: Chime Ogbuji <chimezie@gmail.com>, Andrea Splendiani <andrea.splendiani@bbsrc.ac.uk>, MMVagnoni@mdanderson.org, James Malone <malone@ebi.ac.uk>, HCLS <public-semweb-lifesci@w3.org>, Jonathan Rees <jar@creativecommons.org>
Message-Id: <82F75E8B-3EAD-4B1C-BF83-BEA48731C01B@ihmc.us>
To: M. Scott Marshall <mscottmarshall@gmail.com>
If I might summarize this debate, the arguments for using opaque and meaningless identifiers seem very similar to the argument that since there is a danger of shooting oneself in the foot, that therefore it is best to prevent this by having all feet surgically removed at birth.

Still, HCLS is, thank God, a comparatively small community taken at a planetary scale, so I guess y'all should do whatever suits you. Just as long as this particular madness is not infectious. 

Pat Hayes


On Jun 20, 2011, at 3:15 PM, M. Scott Marshall wrote:

> Hi Chime,
> 
> The main reason is that when semantics and natural language are
> inserted into identifiers, some identifers are doomed to become stale
> as thinking evolves or changes about the semantic representation. Or
> when a new 'name brand' is created for that namespace: I think that
> the best example of this was provided by Jonathan Rees for Shared
> Names - ever heard of 'locuslink' identifiers? I believe that Entrez
> Gene occupies the name branding of that space now.This is precisely
> the sort of problem that Shared Names would like to avoid by serving
> (non-ontological) identifiers from a 'neutral namespace'. In
> ontologies, the same principle applies (I see that Helena has supplied
> a good example).
> 
> I agree with Mark about proper tooling - the tools should
> automatically display labels. It's true that I don't know of a SPARQL
> editor that does this to a satisfying degree yet, (except for one:
> SPARQL Assist Lanugage-Neutral Query Composer from McCarty et al,
> shown at SWAT4LS in Berlin :) See Mark's post.) but that is not a
> reason to create identifiers and your knowledge representation in a
> way that won't stand the test of time.
> 
> Shouldn't we consider RDF to be the bytecode of knowledge? Although I
> understand the difficulty of dealing with non-human readable
> identifiers in SPARQL and RDF, I believe that we are now looking at
> bytecode and complaining that it isn't human readable. It's true that,
> until the tools are available, it is difficult to write SPARQL
> queries. But if we applied the same logic to gene accession numbers,
> where would we be now? The SPARQL queries will eventually be 'under
> the hood', supplying labels to a GUI near you. :)
> 
> Cheers,
> Scott
> 
> On Mon, Jun 20, 2011 at 9:34 PM, Chime Ogbuji <chimezie@gmail.com> wrote:
>> On Monday, June 20, 2011 at 3:08 PM, Andrea Splendiani wrote:
>> 
>> Hi,
>> sorry to jump on this thread like this...
>> 
>> To be honest, I'm kind of concerned by the insistence on semantic-opaque
>> identifiers.
>> 
>> I am as well and I have been for some time.
>> 
>> I understand the reason for them,
>> 
>> Actually, I would be interested in hearing the reason for them enumerated,
>> because I have had a hard time imagining what could possibly offset the
>> (significant) impact on readability that it has on biomedical ontologies.
>>  The barrier is already high for non-logicians and non-semantic web
>> aficionados to use biomedical ontologies.  Why set it any higher?
>> -- Chime
>> 
> 
> 
> 
> -- 
> M. Scott Marshall, W3C HCLS IG co-chair, http://www.w3.org/blog/hcls
> http://staff.science.uva.nl/~marshall
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Tuesday, 21 June 2011 01:19:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:52:47 UTC