Re: Demo SPARQL notes

I with Bijan on this issue.

However complex the current OWL representation may appear, it's  
considerably more terse than the expression of this same info in a  
relational model.  Yyou can write some very effective SPARQL queries  
against it, after playing with it a bit to get a more complete  
understanding of what the ontology is trying to express.

I've certainly been having pretty good luck creating SPARQL queries -  
even by hand (i.e., without fancy end-user oriented tools) - against  
some of the similarly modeled data in the NeuroCommons repository.

I would agree the current OWL ontologies maybe a little more  
application-specific than I would want in the long-term, but I think  
they can still be used quite effectively right now.

Cheers,
Bill

On Apr 17, 2007, at 11:10 AM, Bijan Parsia wrote:

>
> 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.

Bill Bug
Senior Research Analyst/Ontological Engineer

Laboratory for Bioimaging  & Anatomical Informatics
www.neuroterrain.org
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