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

Re: I read a challenge. was, Re: [gofriends] GO ontology in OWL format

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Fri, 14 Sep 2007 10:34:20 +0100
Message-Id: <AFF9DAFA-204E-4B9F-A1C0-DE86CB997AE7@cs.man.ac.uk>
Cc: public-semweb-lifesci hcls <public-semweb-lifesci@w3.org>
To: Alan Ruttenberg <alanruttenberg@gmail.com>

On 14 Sep 2007, at 10:04, Alan Ruttenberg wrote:

> Seen on the gofriends list:
>
> On Sep 12, 2007, at 1:20 PM, Chris Mungall wrote:
>
>> Let me also give you some information on the results of our  
>> experiments using OWL and Sesame, as part of a different project  
>> outside GO. Triplestores such as Sesame seem to work best when you  
>> are storing instances rather than classes and class level  
>> relations. Sesame has no knowledge of OWL entailment rules (there  
>> is an addon called OWLIM that provides this). This means you are  
>> out of luck if you want to make queries over the GO such as "what  
>> is the nuclear chromosome part of?".
>>
>> You may be tempted to treat GO classes as instances and query  
>> these using normal RDFS semantics (for example, by loading the  
>> semi-deprecated GO RDF-XML file). This will give you better  
>> results in the short term, as you will be able to ask queries such  
>> as the part_of one above. However, this approach may turn out to  
>> be a dead end in the long run.
>>
>> In my opinion SQL (with entailments pre-computed)

Isn't that the rub?

It the arbitrary case you cannot pre-compute the entailments (since  
they are infinite). In many practical cases, pre-computation fails  
(hrm...trying to recall exactly the result from the ESWC  
paper...maybe quadratic blow up for a well designed closure? Oh, see:  
<http://www.eswc2007.org/pdf/eswc07-munoz.pdf> theorem 6, but  
entailment can still be done n log n. The algorithm, however, is  
quite reasonable, though I'm not enough of a SQL maven to say how  
best to do it...there seem to be some tricky bits for core  
relational; and this is all for ground entailment, i.e., no bnodes  
under bnode semantics or with renaming/merging).

This is presuming that you are using an ontology with roughly rdfs  
expressiveness, i.e., subclassing, subpropertying, domain and  
ranging///.

>> still turns out to be a far superior choice to existing semantic  
>> web technology

In which facets? (Clearly views are very nice for simplifying some of  
the more complicated queries like "All genes in Drosophila annotated  
to 'nucleus'". SPARQL lacks aggregates, etc. etc.)

>> - I'd be interested to see the SPARQL equivalents of the following  
>> queries:
>> http://wiki.geneontology.org/index.php/Example_Queries
[snip]

I agree that it's a very nice list.

It would be interesting, at least to me :), to figure out exactly  
what it would be to use SQL directly against RDFS in some reasonably  
standard and portable and semantically correct way. Seems like it  
should be feasible for ground RDFS (or ground like). One issue is the  
effect of table layout, but perhaps one could have bilateral mappings  
expressed via something like GRDDL or Fresnel.

Cheers,
Bijan.
Received on Friday, 14 September 2007 09:33:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:00:49 GMT