Re: Issue with Problem Oriented Medical Record OWL Ontology

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

Received on Thursday, 12 April 2007 02:13:54 UTC