Re: Is ontology an information resource?

Yoshio, let me have a try at this. You've poked at this in such a way  
as to have Richard expose a whole bunch of confusion in the  
underlying architecture, at least insofar as it intersects the  
semantic web. I'm apologize in advance if this confuses. I don't like  
confusion, but I like even less the appearance of lack of confusion  
where there is in fact much.

On Oct 20, 2007, at 9:56 AM, Richard Cyganiak wrote:

> On 18 Oct 2007, at 16:47, Yoshio Fukushige wrote:
>> OK, now that the Classes and properties ARE non-information  
>> resources,
>> requests for them should be answered with status code 303 (ignoring
>> other non-relevant possibilities of codes like, for example, 404).
>
> Yes, assuming that you use slash URIs for your classes and properties.
>
> (You can also use hash URIs, like for example the RDF, RDFS and OWL  
> namespaces do. This gives us URIs like http://www.w3.org/2002/07/ 
> owl#Class .)

What is unsaid here is that if you use hash URIs *you can not make  
requests for them to a server at all*. Instead what happens is that  
the server can only receive a request for the uri in front of the  
hash. So you can't request
http://www.w3.org/2002/07/owl#Class. You can request  http:// 
www.w3.org/2002/07/owl and then it's up to you to figure out what in  
the response is relevant to #Class.

>> Then to what URI (IRI) should the Class/property URI be re-directed?
>>
>> It is to a URI which dereferences to the defining ontology, right?

There are two answer to this, depending on what you want your  
audience to receive. You can redirect to the defining ontology, but  
then if the client was seeing something more directly about the class/ 
property they won't. Or *you* can decide what you want your clients  
to see, for instance annotation properties about the class/ 
properties, as well as their defining axioms. However, since it is  
difficult to extract, in general, only those axioms that impinge on  
the definition, you would include an <owl:imports> of the full  
ontology, and perhap (for a different set of clients a statement  
using rdfs:isDefineBy to explicitly note that the class/property is  
defined by the full ontology.

This approach tries to provide useful information, while at the same  
time retaining the same semantics by making sure something you might  
have missed is covered, via the owl:imports.

With recent work on ontology modularization, a third option presents.  
In that case the owl:imports could instead import a portion of the  
defining ontology that would ensure that any entailments made using  
it would be the same as if the full ontology was used.  
rdfs:isDefineBy could still point to the original ontology.

With large ontologies (biomedical ontologies can run into the  
hundreds of megabytes) the approach I outline here is much friendlier  
for SW browser applications such as the tabulator. OTOH no compromise  
on semantics is made.

> You don't *have* to make your class URIs and properties  
> dereferenceable, but I think most people would agree that it's a  
> good idea and a useful thing to do.
Richard and I definitely agree on this.

>> But should it be the URI of the ontology as a generic  
>> (information) resource
>> or the URI of one of its representation (specific resource), for  
>> example
>> RDF/XML file?
>

Let's untangle this a bit:

1) You asked about a "specific resource". There are certainly a set  
of resources which return one and only one representation, and it is  
reasonable to call those specific resources. IIRC Timbl called them  
fixed resources.
2) As I've pointed out, there is no specification of what should be  
served up when making a request using the URI of a class/property,  
other than it should be a 303. Since what's on the other side of a  
303 is hardly specified, you can return pretty much what you want.  
I've suggested what I think should be done above.

> I'm not sure what you mean. Representations don't have URIs.

This is, at least, confusing. First, we know that there are these  
"specific resources", which, when we name them, feel a lot like we  
are naming representations. Second, there are other places that URIs  
go, such as in Content-location: headers, where it would seem that  
they in fact do refer to representations. After all, resources aren't  
series of bytes, where representations are. If you make a request for  
a range of bytes, you must be, therefore, talking about a  
representation. You can't get a md5 of a resource. You can get a md5  
of a representation. At least that's the best I can figure out.

> And an RDF/XML file published on the web *is* an information resource.

I don't think so. Again, using my best understanding of the  
terminology, a RDF/XML file is a representation. When we publish it  
on the web we create a new thing, an information resource, which has  
this file as one(the only one?)  of its representations.

> Keep in mind that, at the end of the day, “information resource” is  
> just a fancy term for “web document”.

Too narrow, AFAICT, though probably one of the roots of the confusion  
we are all having. Assuming that a web document is a kind of document  
(that may be an invalid assumption - correct me if I'm wrong) and  
since documents can't respond to messages, it doesn't make sense to  
make a POST to a web document, whereas one *can* do a post to an  
information resource. (or can't I Richard?). Either that, or a POST  
could never get a 200 response.

> Let me give you an example. Here are some classes and properties  
> from my ontology:
>
> http://example.com/myOntology/myProperty
> http://example.com/myOntology/myClass
>
> They all could 303-redirect to this URI:
>
> http://example.com/myOntology.owl
>
> At this URI, I could serve an RDF/XML representation of the  
> ontology. Nevertheless, that URI indeed identifies *the ontology*,  
> an information resource, and not a particular representation.
>
> (Again, in a real application I would probably use hash URIs for  
> the classes and properties.)

In a real application I would try to make my server respond more  
carefully to a request for a class/property than simply pointing to  
the defining ontology. If the definition ontology is the size of the  
NCI thesaurus, this is essential if you want to use tools such as  
tabulator effectively.

Regards,
Alan

Received on Saturday, 20 October 2007 15:19:13 UTC