SKOS & FOAF mystery solved (pretty much)

Hi Dan,

I believe I've figured out the root of our SKOS & FOAF problems, and  
I could really use your feedback on this diagnosis.  I may be  
mistaken, but I don't believe I am.

We were using a previous version of SKOS.  Worse than that, we were  
using what appears to have been a lesser known experimental file -  
the OWL DL version of SKOS:
	http://www.w3.org/2004/02/skos/core/owl-dl/skos-core-owl-dl.owl

Having formerly worked in the STM industry with information  
scientists who've been digging away at these issues for a LONG time,  
I recognized after scouring the web SKOS was really the only artifact  
available in the RDF and/or OWL world that came close to supporting  
vocabulary management in a manner commensurate with this long, hard  
won knowledge from the info science/library science community.  As  
head of product development at the publishers of the Biological  
Abstracts (BIOSIS), I had the task of building profitable products  
from a complex information repository and that experience taught me  
not to tread lightly over this very important issue of structured  
lexical repository management.

So - back to the problem...

That file is still available via that http link.  The only detail in  
the owl:ontology header is:
	$Revision: 1.1 $

This alone should have been a warning against using it.  Certainly,  
the SKOS site made it clear SKOS IS a work in progress.  At the time  
I first incorporated SKOS into the BIRNLex ontology we are creating  
within BIRN, I had a pressing deadline to get something out - and  
many other tasks to work on, so I delayed actually getting in touch  
with you all directly at that time.  As you may be aware, it is often  
the case in this field of biomedical ontology development, tools and/ 
or resources from the community may not be QUITE ready for any given  
set of application requirements, so it's not unusual for groups to  
forego the work of others (or at least decide to get on with their  
pressing tasks without directly using the not-quite-ready tools of  
others).  I was loathe to do this where SKOS was concerned because:  
it looked SO CLOSE to what we required; it was already in OWL DL; and  
- MOST IMPORTANTLY OF ALL - to create your own arbitrary technique  
for specifying these lexical details greatly mutes the value of being  
systematic, as however useful your effort turns out to be internally,  
there's no guarantee it will be of much use to the community at  
large, if you grow it yourself.  I think one of the convincing  
factors for me was it was being used to express WordNet - and the  
folks at NLM were considering it for use within the UMLS.

Still - as we were working in Protege-OWL and trying to remain within  
the OWL DL specification - it seemed like a godsend to have found it  
ready for use, full of the SKOS properties we needed to use to  
provide a structured lexical specification for the BIRNLex ontology.

Of course, once we had SKOS in our large and growing ontology -  
leaning on it heavily to document the curatorial process and enhance  
it's associated lexicon - there was no EASY way to go back.

As you may know, Daniel Rubin has participated in our BIRNLex  
ontology curatorial activity at least as an interested outsider and  
guide to adopting best practices.  Soon after this initial investment  
in SKOS, Daniel starting working with you more directly, and I  
assumed we'd hear through him, if we were going about things  
incorrectly.

And so we have...

Now we are working to produce release v1.0 of BIRNLex, and we're  
being very careful to use best-practices for distributing ontologies  
for public use in the biomedical informatics community.  One of those  
practices is the make certain:
	1) for any OWL and/or RDF resources you re-use via namespace  
specifications or owl:imports - or whatever mechanism - you make  
certain you are using a network URI (URL currently) to access that  
external resource (not a locally stored copy)
	2) you are using the "preferred" URI as given by the authority  
curating that resource.

We therefore switched our SKOS references from that previous SKOS OWL  
DL version to the one advertised on the SKOS home page - the NEW SKOS  
home page:
	http://www.w3.org/2004/02/skos/

This is when our FOAF problems began in Protege OWL.  When you use  
owl:import to bring the SKOS core.rdf file into a brand new OWL RDF/ 
XML project, Protege OWL "chokes" on the FOAF namespace assignment in  
that SKOS RDF file, bringing the import process to a halt.  This same  
FOAF namespace def appears in the latest SKOS core.rdf file exactly  
as given in the OWL DL version, but for some reason, Protege OWL  
can't cope with it.  Both open just fine in SWOOP.

BIRN has a very important series of All Hands meetings running  
throughout March, so I really must make a release of the BIRNLex  
files that can be used during those several weeks of meetings.  For  
now, that means sticking with the SKOS OWL DL file, even though I  
know its NOT the preferred version.

With that in mind, my questions to you are:
	A) Will it be possible to keep that SKOS OWL DL file available  
online for the time being, until we can migrate to the preferred  
means of referencing SKOS?
	B) Can you provide us some specific advice on how to best make use  
of SKOS?

With the latter issue, the first thing we will do with this v1.0  
release BIRNLex is to pass it on to Daniel Rubin to have it hosted at  
the NCBO BioPortal.  From there, you and others working within the SW  
Deployment Group will be able to easily peruse what we've been doing  
with it.  I would add we are also working on the OBI ontology and  
contributing significantly to their development of a process to  
handle these same issues in their ontologies.  Alan Ruttenberg who is  
working with you on the W3C SW DG has recently begun to contribute to  
that effort.  We'd very much like to see what we do on BIRNLex be  
commensurate with - or re-used by - OBI.

I greatly appreciate any advice and assistance you can provide to us  
in BIRN to help us to work through this issue.

Cheers,
Bill




On Feb 27, 2007, at 12:25 PM, William Bug wrote:

> Many thanks for this follow-up, Dan.
>
> Sorry for the confusion in my previous email - we were not using  
> "http://xmlns.com/foaf/0.1/20050603.rdf" at all in the past.  I was  
> just using it to see whether I could directly open SOME FOAF  
> ontology.  We'd been using "http://xmlns.com/foaf/0.1/" which  
> previously worked just fine.
>
> As you say - there doesn't appear to be any issue with FOAF per  
> se.  I can certainly use http://xmlns.com/foaf/0.1/index.rdf as a  
> URI to open it directly in SWOOP.  Protege will only directly open  
> Protege project files or OWL files, but I assume namespace specs  
> referencing this URL inside other OWL file SHOULD be OK.
>
> It now appears the problem must be with some change that has taken  
> place with SKOS access.  We were previously using the URL:
> 	http://www.w3.org/2004/02/skos/core#
>
> However, due to other issues we'd been having with URL-based  
> access, we'd all downloaded the other OWL & RDF files we were using  
> via owl:import so as to have local fall back files to access.  It  
> appears we were accessing the local SKOS file more than we'd  
> known.  What's been  happening is we are re-arranging our URL  
> referencing so as to regularize it across all our files for an  
> upcoming release.  In so doing, we are eliminating any of these  
> local dependencies, so that others will not be forced to locally  
> download any additional files in order to use our OWL ontologies.
>
> So - for some reason - we don't appear to be able to access the  
> SKOS "vocabulary" files we are importing - and THIS also somehow is  
> leading to our getting this FOAF error in Protege.
>
> I'll try to work on this some more this evening.
>
> Thanks again for the assistance, Dan.
>
> Cheers,
> Bill
>
>
>
> On Feb 26, 2007, at 11:13 PM, Daniel Rubin wrote:
>
>> Dan,
>> Thanks for the follow up. I'm copying Bill Bug, who is the person  
>> who reported the SKOS/FOAF problem, so he can reply to your  
>> questions below.
>> The tool being used is Protege.
>> Thanks
>> Daniel
>>
>> At 10:46 AM 2/26/2007, Dan Brickley wrote:
>>> Thanks. It certainly ought to be the case that FOAF and SKOS work  
>>> well together. If someone is having trouble, I would like to find  
>>> out why.
>>>
>>> That said, I am having trouble understanding the detail of the  
>>> message.
>>>
>>> http://xmlns.com/foaf/0.1/20050603.rdf is an archive-only  
>>> snapshot of FOAF's RDF description, never intended for use as a  
>>> namespace. Well, people are free to do so, but it would be  
>>> excessively cautious usage, I think.
>>>
>>> It soulds like they are using some particular toolset. Do you  
>>> have any more details?
>>>
>>> For example, http://www.dasbistro.com/~sam/raptor.lisp seems to  
>>> be fixing on that specific URI.
>>>
>>> http://comments.gmane.org/gmane.comp.misc.ontology.protege.owl/ 
>>> 19596 suggests that URI is being used in Protege circles.
>>>
>>> Could you ask if http://xmlns.com/foaf/0.1/index.rdf works OK for  
>>> them?
>>>
>>> Perhaps the problem is with our content negotiation setup. That  
>>> could well be the case. If you can find out what tool is being  
>>> used, I could run some tests...
>>
>>
>
> Bill Bug
> Senior Research Analyst/Ontological Engineer
>
> Laboratory for Bioimaging  & Anatomical Informatics
> www.neuroterrain.org
> Department of Neurobiology & Anatomy
> Drexel University College of Medicine
> 2900 Queen Lane
> Philadelphia, PA    19129
> 215 991 8430 (ph)
> 610 457 0443 (mobile)
> 215 843 9367 (fax)
>
>
> Please Note: I now have a new email - William.Bug@DrexelMed.edu
>
>
>
>



Bill Bug
Senior Research Analyst/Ontological Engineer

Laboratory for Bioimaging  & Anatomical Informatics
www.neuroterrain.org
Department of Neurobiology & Anatomy
Drexel University College of Medicine
2900 Queen Lane
Philadelphia, PA    19129
215 991 8430 (ph)
610 457 0443 (mobile)
215 843 9367 (fax)


Please Note: I now have a new email - William.Bug@DrexelMed.edu