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

Re: Demo SPARQL notes

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Tue, 17 Apr 2007 16:10:57 +0100
Message-Id: <F26C0A35-39AB-412B-BD8E-7C6C2B7D3DFF@cs.man.ac.uk>
Cc: Alan Ruttenberg <alanruttenberg@gmail.com>, public-semweb-lifesci@w3.org
To: samwald@gmx.at

On Apr 17, 2007, at 3:08 PM, samwald@gmx.at wrote:
[snip]
> I am quite interested in your approach of making OWL property  
> restrictions accessible to Sparql queries.
> In general, our demo contains several ontologies that are mainly  
> based on classes and OWL property restrictions. To query the  
> information held in these ontologies directly with Sparql would be  
> quite complicated, as the OWL property restrictions produce RDF  
> graphs that are quite convoluted and hard to query.

I'm not sure exactly what you mean here. Hmm. Do you mean that the  
OWL in RDF/XML syntax is rather convoluted? No argument there :)  
Fortunately, there are alternative syntaxes, including an XML one,  
the manchester syntax, and classic DL syntax. One of my things to  
agitate for in SPARQL/OWL is a pluggable expression syntax (Kendall  
Clark and I did some work toward an XML syntax for SPARQL over all  
which would make this easier). But even if not in the spec, one could  
write transformers from a sane syntax into the canonical syntax  
pretty easierly.

> One way of 'querying' such ontologies would be to define a new  
> 'query class' with necessary & sufficient conditions that are the  
> parameters of the query, run a reasoner, and see which classes are  
> classified as subclasses of the 'query class'.

Are you querying for classes or for instances?

> For example, our current demo script contains the research question  
> "How might beta amyloid alter LTP in CA1 neurons?". This can be  
> answered by using the BrainPharm dataset and setting up a class  
> that has CA1 neurons and beta amyloid as parts and/or participants.  
> I did with Protege and Pellet, and it works.
>
> However, I do not know how this approach could be implemented in a  
> real web environment with the current tools that we have. How would  
> the ‘query class’ be produced?

Do you mean "How on earth could any end user specify this?" Well  
there are lots of ways (few involving exposing even a friendly query  
syntax). For example, in jSpace (<http://clarkparsia.com/projects/ 
code/jspace/>) you can see the queries that are built up by adding  
columns, switching them around, and making selections in a "iTunes  
like" browsing interface (see mSpace <http://www.mspace.fm/>). So  
forms, QBE, and other interfaces could generate a class as well as a  
SPARQL query (and really, classes are a sort of query :)).

> How would it be added to the RDF store?

Would you need it to be added? In Pellet, for example, you can ask  
for the superclasses of an arbitrary class expression without adding  
it to the ontology. This is a pretty normal feature of reasoners.  
OTOH, you could add it, e.g., if you wanted it available for  
subsequent queries. As you may know, we've done some work on  
incremental ontology reasoning under updates. While the best results  
have been, thus far, for abox updates, we got reasonable improvements  
for TBox updates as well. It's hard to make predictions without  
fairly detailed information about the use patterns and loads.

> How should this be implemented with decent scalability? These are  
> all questions that should be obvious, but yet they have been  
> ignored by many influental ontology / OWL developers so far.

I'm not sure what to make of this claim. Some few (to my knowledge)  
"influential" ontology/OWL developers have no need for these things,  
thus they properly neglect them. I don't think their influence  
prevents people from asking and working on these questions and even  
making great progress.

> I think that we will not have a practical answer to these questions  
> in the immediate future.

Since I'm still a bit unclear about the specifics (and practical  
import) of your question, I'll demure.

> Therefore, I think that Alan’s proposal of adding direct relations  
> between class entities is the best solution we have at the moment.  
> Of course, it would be nice to find a solution that would make it  
> possible to keep the resulting ontologies valid OWL DL. Maybe we  
> should set up  annotation properties that are derived from the  
> original properties (e.g. by concatenating ‘_class_property’ to the  
> end of the URIs of the original properties) and use these?

I'm sorry but I haven't followed the whole debate. There are at least  
three sorts of query one might be interested in:
	Semantic [argh, need a better term] TBox/schema oriented query  
(e.g., parents, ancesters of classes, etc.)
	ABox/data query (e.g., instances of classes, arbitrary conjunctive  
queries)
	Metadata query (i.e., of annotations)

(You might want to have all three of these in a single query with  
various types of sharing of variables across sorts.)

Part of my personal goal for OWL 1.1 is to support the representation  
of all this in as clear and sensibly flexible a way so that querying  
in and across these dimensions is robust and effective for applications.

Sorry for any misunderstandings I may have had and then generated :)

The usability of the entire infrastructure is of great concern to me,  
however slight my influence may be. That means that I would very much  
like it for people to be able to say what they need to say, ask what  
they need to ask, and get useful answers. This means that the  
languages must be usable (or have usable tools wrapping them) and the  
backends must work for the relevant problems.

Cheers,
Bijan.
Received on Tuesday, 17 April 2007 15:11:08 GMT

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