Re: Adding addition OWL & RDF artifacts to the NC RDF repository

Exactly, Matthias.

This is why I say there should be some vetting of what's there and  
decisions made as to what would be the most useful without causing  
unwanted problems.

As I mention (and as Chris has in fact already made clear), most of  
what is here can be fairly easily addressed (in the URI/URL sense)  
via algorithmic means.

Both you and Chris point out - not all of what is here would be  
sensible to "mix in" to the growing, high-value NeuroCommons (NC [1])  
repository.

My point in bringing it up is this is a rich source of OWL (possibly  
not of RDF, as Chris points out) of immediate relevance to  
bioinformatics - and some of it  very specific relevance to the goals  
we've had in HCLS.

It would be silly to not give it a thorough vetting, at this stage.

One thing I would add is, as I assume the OWL versions of OBO  
ontologies are derived from the OBO2OWL translater(s), we should take  
a look at some of the details of what that produces.  We may be able  
to provide some advice on how to make to results more useful - or  
find out from the OBO folks how its intended to be used, when that is  
not obvious.  One of the things I'm having trouble with right now is  
the form that OBO ontology entity definitions are provided in these  
OWL translations [2]



Cheers,
Bill

[1] sorry for the unannouced acronym, Chris

[2] For instance, definitions in the PATO OWL file (quality.owl) are  
not visible in Protege.  The OWL version of PATO has an  
AnnotationProperty called "oboInOwl:hasDefintion" that has the value  
"@_:A4843".  Looking in the quality.owl file directly, I see "heart  
shaped" contains the following oboInOwl:hasDefinition XML entity:

     <oboInOwl:hasDefinition>
       <oboInOwl:Definition>
         <rdfs:label xml:lang="en">Having the shape of heart.</ 
rdfs:label>
         <oboInOwl:hasDbXref>
           <oboInOwl:DbXref>
             <rdfs:label>PATOC:GVG</rdfs:label>
             <oboInOwl:hasURI rdf:datatype="http://www.w3.org/2001/ 
XMLSchema#anyURI">http://purl.org/obo/owl/PATOC#PATOC_GVG</ 
oboInOwl:hasURI>
           </oboInOwl:DbXref>
         </oboInOwl:hasDbXref>
       </oboInOwl:Definition>
     </oboInOwl:hasDefinition>

oboInOwl:Definition and oboInOwl:DbXref are defined as owl:Class  
types.  oboInOwl:hasDefinition and oboInOwl:hasDbXref are defined as  
an OWL AnnotationProperty types.  But Protege-OWL v3.x (and probably  
the Jena library calls being used in Protege to parse the content in  
these instances of the oboInOwl:hasDefinition AnnotationProperty)  
have no idea how to parse such complex content contained within an  
AnnotationProperty.  For OWL 1.0, you CAN stuff whatever you like  
inside an AnnotationProperty, but it's going to by and large be  
interpreted as being unstructured text, unless core rdfs or owl types  
are used to provide more structure inside the AnnotationProperty.  Of  
course, if you create AnnotationProperty instances like that, then  
you are no longer in OWL-DL.

For this complex construction:

AnnotationProperty (oboInOwl:hasDefinition)
	Class (oboInOwl:Definition)
		rdfs:label
		AnnotationProperty (oboInOwl:hasDbXref)
			Class (oboInOwl:DbXref)
				rdfs:label
				AnnotationProperty (oboInOwl:hasURI)

Protege-OWL 3.x (and Jena, I assume) doesn't have the slightest idea  
how to represent this information, hence the opaque and meaningless:

	< oboInOwl:hasDefinition>@_:A4843</oboInOwl:hasDefinition>

The entity icons being displayed indicate Protege thinks this is some  
manner of OWL instance.

I should add I do have all the required namespaces declared, and the  
file itself when checked in Pellet 1.4 comes out as OWL-DL species  
and "consistent".

On May 24, 2007, at 3:11 PM, samwald@gmx.at wrote:

>
>
>> Rather than going through and copy & pasting ALL the OWL & RDF links
>> into a text file, I thought I just send this reminder and cc to
>> Chris, as he may have other ideas about how to get these into the NC
>> repository that don't include error-prone copy & pasting or require
>> someone to write a scraper for this page.
>
> I think that we probably do not want to use (and even import) all  
> of the ontologies in the current OBO collection. We should probably  
> focus on the OBO Foundry ontologies and some of the more consistent  
> OBO Foundry candidates. Some of the ontologies would need some  
> remodelling before they can be integrated into a consistent demo  
> scenario in a really useful way.
> For example, the evidence code ontology could better be represented  
> as an ontology of processes of biomedical experiments and techniques.
>
> -- Matthias
> -- 
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
>



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