Re: Trying to summarise: Semantic free identifiers

This entire discussion is simply absurd, if it is supposed to apply to the semantic web generally. OF COURSE people are not going to re-name the RDFS or  OWL vocabulary (for example) with 'opaque' names. Programming languages are not going to use opaque identifiers for their reserved vocabularies, and people are not going to start speaking in numerical codes. This would all be riotously funny if some people did not, apparently, take it seriously.

How could such a crazy idea ever be enforced? Rest assured that the W3C is not going to re-write its standards to require opaque identifiers. If someone feels that http://whatever.com/opacity/045678723  better suits their methodology than, say, http://www.w3.org/1999/02/22-rdf-syntax-ns#domain, then by all means let them assert the equivalence using owl:sameAs. Of course, this will not actually work in OWL (the RDFS namespaces are reserved vocabulary) but no doubt the extensive Tooling which they will build will have its own special reasoners and hence be able to overcome this minor detail. 

This discussion should never have even begun in a Semantic Web forum. Save your energies for more productive discussions, such as how to reconcile the Palestine/Israel conflict. 

Pat Hayes


On Jun 21, 2011, at 2:26 PM, Jim McCusker wrote:

> Personally, I don't want tooling to "help". I want to be able to look
> at what would otherwise be a perfectly readable serialization
> (Manchester OWL, Turtle, etc.) and be able to read and write it
> without constantly referring to lookups. I've seen this discussion in
> the software engineering world many times. Tooling will make it
> unnecessary to to write code directly. UML, GUI builders, etc., etc.
> And yet we always come back to writing code directly.
> 
> Jim
> 
> On Tue, Jun 21, 2011 at 3:13 PM, James Malone <malone@ebi.ac.uk> wrote:
>> So.. a long but useful discussion. That will teach me to open my big mouth :)
>> 
>> Is this fair as the PRIMARY reasons for this difference in opinions:
>> 
>> 1. Having semantic information such as a label in a URI makes it easier
>> to, at a glance, grasp some sort of meaning of a class/predicate and makes
>> SPARQLing and looking at RDF easier.
>> 
>> 2. NOT having semantic information in a URI ensures class definitions need
>> to be looked up before they can be used, hence, reducing ambiguity and
>> that it potentially improves maintainability.
>> 
>> Can 1 be resolved by tooling? Seems to me 2 is happening already and will
>> grow as practice in a lot of the bio-ontology community. If there is a
>> lack of tooling surely this group should be looking at doing something
>> about that - funding, lobbying..
>> 
>> James
>> 
>> 
>> 
>> 
>> 
>>> Hi,
>>> 
>>> I think there is some confusion going on on the subject.
>>> 
>>> We need to name things in an unique way. In many cases codes are just the
>>> best option. No wonder we all have tax-codes and the like, it's easier
>>> than
>>> to try to find a unique name based on some attributes.
>>> 
>>> The case of terminologies is an interesting case, as we need to name
>>> terms.
>>> There is a temptation to use the 'face value' of the term as a name, as
>>> opposed to a code. The former is clearly opening the doors for
>>> ambiguities,
>>> in this context.
>>> 
>>> Beside terminologies, there are many other cases where you name thing:
>>> 
>>> rdf:type
>>> 
>>> owl:Class
>>> 
>>> Is there a need for these to be semantically opaque ? I don't think so,
>>> they
>>> are good for mnemonics and the formal meaning is clearly defined
>>> elsewhere.
>>> 
>>> The original thread didn't start from somebody questioning GO terms... but
>>> the need to replace 'partOf' with a code.
>>> 
>>> To tell a funny story... I have an (unrelated) homonymous in my home town
>>> (which is a bit weird given the size of the town and the frequency of my
>>> last name). Given the identifier clash... I ended up receiving funny
>>> things,
>>> like love letters or urgent calls from unknowns... (not sure I missed some
>>> as well...).
>>> Now, when i went to register a website, which one would be better:
>>> mydomain/AndreaSplendiani
>>> mydomain/001
>>> 
>>> I cannot really see any reason for the latter, and several reasons against
>>> it.
>>> Does mydomain/001 protects friend and lovers of my homonymous from
>>> confusion
>>> ? Most likely not.
>>> 
>>> ciao,
>>> Andrea
>>> 
>>> 
>>> Il giorno 21/giu/2011, alle ore 18.46, Helena Deus ha scritto:
>>> 
>>>> Other standards (outside of semantic web) saw the need to rely on
>>>> numeric
>>> identifiers, even if that created a burden for their users
>>>> e.g. in SNOMED Lung = T-28000
>>>> 
>>>> Of course it is a pain to query SNOMED with "all the diseases that
>>>> affect
>>> T-28000".
>>>> But the fact is that despite the inconvenience of having to fetch that
>>> identifier prior to the query, SNOMED is widely used.
>>>> 
>>>> What is so special about semantic web identifiers that they don't need
>>>> to
>>> follow the same path?
>>> 
>>> Andrea Splendiani
>>> Senior Bioinformatics Scientist
>>> Centre for Mathematical and Computational Biology
>>> +44(0)1582 763133 ext 2004
>>> andrea.splendiani@bbsrc.ac.uk
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> European Bioinformatics Institute,
>> Wellcome Trust Genome Campus,
>> Hinxton,
>> Cambridge, CB10 1SD,
>> United Kingdom
>> Tel: + 44 (0) 1223 494 676
>> Fax: + 44 (0) 1223 492 468
>> 
>> 
>> 
> 
> 
> 
> -- 
> Jim
> --
> Jim McCusker
> Programmer Analyst
> Krauthammer Lab, Pathology Informatics
> Yale School of Medicine
> james.mccusker@yale.edu | (203) 785-6330
> http://krauthammerlab.med.yale.edu
> 
> PhD Student
> Tetherless World Constellation
> Rensselaer Polytechnic Institute
> mccusj@cs.rpi.edu
> http://tw.rpi.edu
> 
> 

------------------------------------------------------------
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 Wednesday, 22 June 2011 03:23:34 UTC