DISQUS

Hmm, a bit odd to post a comment to this weblog, but DC got its first snow all winter today, which is a bit of an odd coincidence.

As for SparqlX, yeah, I'd like to see that revived; but DAWG shouldn't be distracted with it at this point, I think. Better that we should just make it a Member Submission and see what happens.

Actually, we could do something with it when we do something with SPARQL-DL?

Yes, at least there is something to disagree about re: expressivity. Syntax *is* user-interface, but for such a small group of people, and the Syntax Fetishists in the SemWeb world are so uniformly *bad* at syntax, it's jut enervating.

But, in general, I agree.

The interesting thing is that in this latest conversation about OWL 1.1, the people who oppose 1.1 often claim that a revision now (or, really, *this* revision now) sends a destabilizing message. My impression is exactly the opposite. The LifeSci people, for example, scream every day for qualified cardinality restrictions. So QCR got added.

Where I come from, that's not destabilizing (or evidence of destabilizing), that's being responsive to customer needs. I think that's a good thing and sign of health, not reason for worry.

Danny,

Your primary concern is obvious (as you say: But how many of the DL applications you’ve seen actually use the web?; But how compelling is OWL for use on today’s web?; What does it offer in its own right to the typical web developer?; and
Although OWL is appropriate in specialist domains, and the web can be used to connect these specialist islands, this seems far removed from hooking onto the web at large.), but that's not my concern.

I want to solve hard problems for my customers, and while they always "use the Web" in that they use stuff like HTTP and XML and RDF and SOAP, etc., none of them "use the Web" in the sense that you care about.

But what I continually fail to understand is why Public Webbers like you seem to want to deny or take away or denigrate or otherwise suggest that if some technology isn't used on "the public web", then it's not interesting or useful or valuable or, at least, isn't part of the Semantic Web.

This move is SO boring and doesn't really help anyone at all.

(FWIW, I said pretty clearly that my comments re: DIG 2.0 were in regard to SPARQL Protocol, not SPARQL the query language, so your DIG+OWL versus RDF+SPARQL is irrelevant.)

Has it occurred to you that your 80/20 isn't the same as my 80/20? There isn't just ONE 80/20.

Or to put it yet another way: my business model is to be seen as the place to go when you find that yr problem space is "in the 20"; that is, I want to be the place to go where "RDF doesn't work", when you need more semantics, etc.

If that's not on the Public Web, that's fine with me. That's of almost no concern whatever.

What is of concern to me -- or, rather, of interest -- is that on both ends of DL people keep trying to convince me that DL is useless. People on the low end keep assuring me that all the action is really in OWL Lite, OWL Tiny, OWL--, RDF++, etc etc. But then other people (often the SAME people!) also assure me that all the real action is in OWL Full, FOL, etc etc.

Why are both groups so opposed to DL?

It's not only a reasonable academic subdiscipline but people with hard problems find DL sometimes helps solve those problems. There are DL vendors and clients and OWLED is a DL community event. And we're all very happy to carve out what we think of as "practical expressivity". (I'll also point out that DL generally and OWL 1.1 groups specifically love interesting, tractable fragments of DL, so it's not as-if we disdain lesser expressivities. Every DL person I know continually harps on using just enough expressivity to solve a problem and no more. Surely this is THE right approach all across this spectrum?)

What I don't get is why proponents of both less and more expressive logics than DL feel this unending need to suggest DL is useless or the wrong way forward, etc.? Don't you all have better things to do?

Finally, as Bijan points out in his most recent post, there is NO moving away from RDF/XML proposed in OWL 1.1 charter or specs. The people behind OWL 1.1 specs repeatedly affirmed this point at OWLED.

The idea that another, more human-friendly syntax (like Manchester OWL Syntax) moves OWL away from RDF makes no more sense than the idea that Sir Tim's N3--another, more human-friendly syntax--moved anyone or anything away from RDF/XML.

If that's yr primary worry, then, congrats, you don't really have a worry! :)

Re: paucity of SPARQL Protocol; if you compare the feature set of DIG 2.0 to SPARQL Protocol you'll probably see what I mean. SPARQL-P only supports conjunctive query; an original design draft supported what we might call "KB management" and a more realistic set of KB operations, like adding or dropping a KB, as well as adding and deleting triples to or from a KB; finally, there was a method to introspect the KB to retrieve a document describing its capabilities, datasets, etc (in a language tentatively called SADDLE)... But none of this achieved consensus on DAWG, the majority of which's members were more interested in the simplest protocol possible.

In fact, this demand for protocol simplicity went so far that it was often v. often claimed that the SPARQL Protocol should fit on a single side of one piece of paper.

I was (I wrote the original design draft w/ a more featureful protocol) and remain a protocol maximalist, in that I wanted more features in SPARQL-P, and I'm now v. interested in C&P supporting DIG 2.0 for some of our work, where it's just far, far more valuable. I suspect, too, that it can be made a proper superset of SPARQL-P, making some of this moot.

(One weird thing: I haven't looked at the DIG 2.0 specs, but they should have used WSDL to describe their abstract and concrete bindings, IMO.)

I very much suspect C&P to implement and support DIG 2.0 for (our) Pellet.

Okay, so I prefer Sesame because it is better designed and implemented. The Sesame Sail architecture is relatively easy to extend; we did so with surprisingly little effort.

And as a recent RDF database shootout attests, Sesame is significantly faster RDF database than Jena. In our tests it's not even close.

Also, when you've been around software and written enough code, you start to just form a sense for what's good. My nose tells me Sesame is better.

As for SPARQL and Pellet, I probably wouldn't make a decision based on temporary advantage. SPARQL is coming to Sesame sooner than later, and I'd be surprised if one couldn't make Pellet and Sesame play nicely. (It depends on what you really want them to do.)

There are two OWL reasoners listed the Sesame site (BOR and OWLIM). I couldn't make any kind of useful recommendation w/out knowing more about yr situation.

As for query languages, Sesame includes RDQL and SeRQL. I don't know how stable the 2.0 stuff is, but I'd be surprised if it's very long before it's useful in production settings.

But I think of this stuff as a temporary (and limited) advantage at best. :>

Dave,

Yeah, lotsa OWL reasoners are focusing on different things, which I take to be a mark of an active, but immature market. That's a good thing and it does make comparisons complicated. I rank Pellet as best because it's open source, reasonably fast, has a very clever, engaged development team, is very feature-rich (I meant to say, btw, that it's probably more feature-rich than any proprietary or open source OWL reasoner), and has an engaged growing community of users. I give a lot of weight to the fact that the Pellet development team is engaged in Semantic Web research at a fundamental level, including stuff like e-connections, which I think are the bee's knees and very promising.

You said "Pellet's the best RDFS and OWL editor for me". Did you mean to say "SWOOP"?

I know about Jena, of course, and have some experience with it, both first and second hand. Let's put it this way: if I were building a SemWeb application and had to use Java, and so had to choose between Sesame or Jena, I would choose Sesame 10 times out of 10.

I don't know what you mean about "Java systems below Pellet, SWOOP, and the SPARQL frontend" -- but I should have mentioned yr SPARQL frontend as an alternative to Leigh's, I just couldn't remember the name and got sloppy.

A link here would be very welcome.

FaCT++ is open source and certainly faster for many things.

Yeah, I knew it was faster for some things, but I somehow missed that it's open source. Cool. I'm still sticking with Pellet, but I guess now it's more of a homer-choice than before.

As for Kowari, well, yes, it stinks in many ways. But then that was kinda my point; an earlier draft had a bit section on how much RDF databases stink. As you know, they pretty much all suck across the board. But at least they do so in interestingly different ways.

There are lots of other interesting categories, including the one you point out -- in that category I'd name Redland, rdflib, and SWI-Prolog as worth a look-see. That case is, for me, anyway, almost entirely dominated by host language, since it's typically in-process with the code yr already writing or have written.

(erp... in case it's not clear admin == Kendall. :)

In the future directions bit, are you considering saying anything about SADDLE? (Which was, for those not following along at home, the initiated-then-abandoned service description language DAWG played around with.)

I think there's some chance that SADDLE will be on DAWG's plate if or when there's a rechartering.