W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > April 2007

Re: Issue with Problem Oriented Medical Record OWL Ontology

From: William Bug <William.Bug@DrexelMed.edu>
Date: Wed, 11 Apr 2007 23:00:49 -0400
Message-Id: <B326E9DF-8F52-4B3C-B6AD-707C5D0084D5@DrexelMed.edu>
Cc: Jim Hendler <hendler@cs.umd.edu>, Holger Knublauch <holger@topquadrant.com>, Dan Brickley <danbri@danbri.org>, Richard Cyganiak <richard@cyganiak.de>, Alan Ruttenberg <alanruttenberg@gmail.com>
To: public-semweb-lifesci hcls <public-semweb-lifesci@w3.org>
I've experienced similar "weirdness" when working with the OWL  
version of SKOS (both the official RDF version and unofficial OWL  
version of SKOS import FOAF).

Meaning no slight either to Protege-OWL (v4 especially) or to  
Topbraid Composer (and EXCELLENT tool), I've been finding it  
extremely helpful to have SWOOP on hand, especially when debugging  
these sorts of issues, since it appears to do the least behind-the- 
scenes meddling.  It was critical to my troubleshooting the FOAF/SKOS  
problems I was having a while back.


On Apr 11, 2007, at 10:13 PM, Alan Ruttenberg wrote:

> Ho Ho. Funny you should mention this. I was just complaining about  
> it yesterday. In this snippet it is me first, alternating with  
> Richard Cyganiak. (The "weirdness" that Jim is referring to is that  
> even requests for content-type: application/rdf+xml to the foaf URL  
> return html)
>>> For example I am terminally confused by FOAF. What does the name   
>>> "http://xmlns.com/foaf/0.1/" refer to?
>> That's the FOAF vocabulary specification. A document, since GET  
>> returns 200. It's available in HTML format, and may or may not be  
>> available in other formats.
>>> What does this mean (from foaf rdf)?   <rdfs:isDefinedBy  
>>> rdf:resource="http://xmlns.com/foaf/0.1/"/>
>> The subject is defined by the FOAF vocabulary specification.  
>> rdfs:isDefinedBy doesn't constrain the defining document to any  
>> particular format.
>>> How does a SW agent get the rdf for http://xmlns.com/foaf/0.1/ 
>>> Organization ?
>> It can't get the RDF since the FOAF folks have do neither GRDDL  
>> nor a <link> header nor content negotiation. FOAF gets away with  
>> this because everybody has to support FOAF, and so everybody just  
>> hardcodes the URL to their RDF.
> Guess FOAF isn't quite getting away with it :)  I'm not sure why  
> they ever thought they could.
> Emanates from a criticism I make about content negotiation being  
> bad semantic web practice.
> http://lists.w3.org/Archives/Public/semantic-web/2007Apr/0060.html
> It's my turn to respond. I'm reading about Content-Location  
> headers, from RFC2616 - HTTP1/1. Here's a bit I'm currently trying  
> to digest. It's not going down very well.
>> The Content-Location value is not a replacement for the original  
>> requested URI; it is only a statement of the location of the  
>> resource corresponding to this particular entity at the time of  
>> the request. Future requests MAY specify the Content-Location URI  
>> as the request- URI if the desire is to identify the source of  
>> that particular entity.
>> A cache cannot assume that an entity with a Content-Location  
>> different from the URI used to retrieve it can be used to respond  
>> to later requests on that Content-Location URI. However, the  
>> Content- Location can be used to differentiate between multiple  
>> entities retrieved from a single requested resource, as described  
>> in section 13.6.
> Section 13.6 discusses the "Vary" header. More fun (but only if you  
> care about what URIs refer to).
> -Alan
> On Apr 11, 2007, at 9:34 PM, Jim Hendler wrote:
> [snip]
>> However, I think the bigger issue here is that there were (and I  
>> believe still are) some weirdnesses in the machine readability of  
>> the FOAF namespace ( http://xmlns.com/foaf/0.1 ) and that a number  
>> of systems have problems with it (I notice if I try to load it  
>> directly into SWOOP I still get XML parsing errors).  Lots of  
>> systems have done various work arounds for this -- so when you  
>> report your error to the Protege mailing list, you might also send  
>> it to the FOAF one, we've been complaining about this for a couple  
>> years now, maybe if some other folks yell as well we can get it so  
>> that the most used Semantic Web vocabulary will actually conform  
>> to the standards it promotes :-)
>>  -JH
> On Apr 11, 2007, at 7:35 PM, Noah Cohen wrote:
>>>>  I have protege version 3.2.1 build 365 and JDK 1.5.0
>>>>  If I run this ontology through a verifier, it verifies the  
>>>> ontology seemingly without a problem.
>>>>  If i try to load the ontology directly from http:// 
>>>> metacognition.info/ontologies/problem-oriented-medical- 
>>>> record.owl I get some very interesting error:
>>>>  WARNING: [ProtegeOWLParser] Warning: Trying to add import for  
>>>> external resource:
>>>>   http://purl.org/dc/elements/1.1/ --  
>>>> DefaultProtegeOWLParserLogger.logWarning()
>>>>  INFO: [ProtegeOWLParser] Importing http://purl.org/dc/elements/ 
>>>> 1.1/ (from Redire
>>>>  ct to http://protege.stanford.edu/plugins/owl/dc/protege-dc.owl  
>>>> <http://protege.stanford.edu/plugins/owl/dc/protege-dc.owl>)
>>>>  The resource p1:chime has the rdf:type http://xmlns.com/foaf/ 
>>>> 0.1/Person which is
>>>>   not a class but a  
>>>> edu.stanford.smi.protegex.owl.model.impl.DefaultRDFUntypedRes
>>>>  ource
>>>>  Suggestion: In many cases the problem is a missing owl:imports  
>>>> statement to the
>>>>  classes file which defines the correct type of http://xmlns.com/ 
>>>> foaf/0.1/Person
>>>>  It seems to me that it cannot distinguish the foaf Person  
>>>> class, with or without the foaf imports statement.  If someone  
>>>> could please assist here, it would be of great help.  Thank you  
>>>> in advance,
>>>>  Noah

Bill Bug
Senior Research Analyst/Ontological Engineer

Laboratory for Bioimaging  & Anatomical Informatics
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
Received on Thursday, 12 April 2007 03:01:11 UTC

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