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: Wed, 18 Apr 2007 01:35:05 +0100
Message-Id: <9F57DED0-10BE-41D7-8711-397757C2B634@cs.man.ac.uk>
Cc: public-semweb-lifesci@w3.org
To: samwald@gmx.at

On Apr 17, 2007, at 7:28 PM, samwald@gmx.at wrote:
>>> 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 I meant the RDF triple structure, independent of any syntax.

Sorry, I meant to say the RDF syntax, not the RDF/XML per se.

So in sparql, they use a turtle variant. I don't like any of them for  
a number of reasons, including the unwieldy names and the awful  
naming of syntactic structures (e.g., I don't want to write out that  
a certain class expression is a restriction, or that "and" is  
"intersectionOf"; bleah).

(You might look at our recent SPARQL/DL paper:
which *does not* address syntactic issues of the sort we've been  

>> Are you querying for classes or for instances?
> Classes.

Ok. Are you only querying for subsumption and equivalence relations,  
or are you trying to do concept matching, e.g., "Retrieve all classes  
that a defined in terms some sort of restriction on property P"?

>> Do you mean "How on earth could any end user specify this?"
> No no, in this case I was mainly thinking about the developers.

Developers are end users....to someone :)

> Of course we can fix anything (e.g. overly complicated RDF graphs  
> because of OWL restrictions) through adding new features (e.g.  
> using reasoners instead of Sparql queries,

Some SPARQL engines use reasoners, e.g., Pellet, which evaluates  
SPARQL queries.

> adding a macro function to Sparql engines), but I would rather  
> prefer simple and elegant solutions. One of my main attractions of  
> RDF to me was the fundamental simplicity of its approach, and this  
> simplicity would get lost by taking this path.

I have a different perspective, i.e., I do not think RDF is  
fundamentally simple, and it's certainly not a simple approach to  
many problems it has been applied to. But that's not quite here nor  

> Of course, this is just personal preference.

As you say. But again, when evaluating the impact of a technique on  
users we have to know something about the users in question. I know  
some heavily RDF oriented users who claim to strongly prefer the  
verbose triple based syntax for class expressions, even for authoring.

Personally, I think they're nuts ;)

>> 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.
> I have to confess that I was not aware that Pellet offers that  
> feature.

Most reasoners do. If you look at the DIG ask forms, i.e., in:
pp. 8-9, you'll see that you can pop in arbitrary class expressions  
(see figure 12).

> How would you judge the scalability of this approach with the  
> upcoming version of Pellet,

Which approach? Pellet has had a DIG server for a while.

> e.g. for an ontology containing around 200.000 triples, would it be  
> possible to run a webserver that uses this approach to answer  
> concurrent queries of dozens of users without excessive lag?

# of triples is an exceedingly crude measure that really doesn't give  
me enough info so say. But I think that, with compromise and tuning,  
there are plenty of ontologies that fit this scenario that could be  
made to work on reasonable server hardware. You'd want help in a lot  
of cases, but it's not out of reach by any means.

FWIW, the absolutely best way to get traction from implementors,  
other than by funding them, is to put out a real or very realistic  
case, esp. if it doesn't work (easily) on their current versions.

>> Sorry for any misunderstandings I may have had and then generated :)
> Oh, your mail was very helpful. Thanks!

You're welcome.

Received on Wednesday, 18 April 2007 00:35:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:52:30 UTC