« The Tutorial is Done
Not so alternate a view of OWL 1.1 »

OWLED 2006 is Here

by Kendall Clark

So Evren and Mike and I flew down to Atlanta from the DC area yesterday to attend OWLED in Athens, GA. Flights were fine but the drive from Atlanta to Athens was dreary and annoying. Too much traffic. Two high points: first, I rented a Dodge Charger, which is a big car with a bigger engine, so at some point I said to Mike, very calmly, “wow, I’m going 105…”; second, we got to eat at The Varsity, an Atlanta legendary hot dog stand, which has a “branch office” in Athens. Evren seems to love chili dogs as much as I do, a fact I found happily surprising.

OWL (well, DL, really) is one of those kinds of technologies that gets dismissed as too academi or theoretical to be of any use, but which actually gets used in real problem domains (annotating brain imaging artifacts, for example, or doing drug research) all the time. I don’t really know what to make of this common fact, except that these critics seem not, more often than not, to really understand OWL at all.

At any rate, so far, for the first two sessions, we’ve heard talks on the Manchester OWL Syntax (which I hadn’t seen before, but seems quite scribbable—the N3 of OWL, perhaps?); presentation of a visual query language for OWL; an interesting talk about DIG 2.0 (which really highlights the paucity of SPARQL Protocol, alas); as well as some other syntactic sorts of bits. But the second session is full of Life Science applications; that is, real applications.

Maybe the point isn’t that OWL is unreal but that it’s hard?

This entry was posted on Friday, November 10th, 2006 at 11:27 am and is filed under OWL, Pellet, SemWeb. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Viewing 10 Comments

    • ^
    • v
    an interesting talk about DIG 2.0 (which really highlights the paucity of SPARQL Protocol, alas)

    Are there slides from that talk? I'm particularly interested by the "paucity" of SPARQL. Why is SPARQL insufficient - which features should it support in your eyes?
    • ^
    • v
    There's quite a step from e.g. object-oriented programming even to the idea of using RDF as a simple data language. I still struggle with the finer points of OWL and I've been playing with this stuff since DAML (and have used languages like Prolog in the past). So I'd say yes, OWL is hard.

    Clearly OWL is useful, demonstrated by the LifeScience apps you mentioned. But how many of the DL applications you've seen actually use the web? A typical web application these days is a HTML interface to a SQL backend, tied together with PHP, perhaps with one or two dangling quasi-proprietary service interfaces. The step from there to mapping to an RDF model and exposing a SPARQL interface is a big one, but when mashups are calling there is at least some motivation.

    But how compelling is OWL for use on today's web? Ok, parts of are extremely useful adjuncts to RDF - specifically FPs/IFPs (and I personally think that when designing vocabs it's worth treating OWL DL as the default and only falling back on Full when there's a really good reason). What does it offer in its own right to the typical web developer?

    I'm optimistic about the spread of RDF, and from an environment rich in that stuff the step to DL is much smaller than from HTML/PHP/SQL, and the advantages of having a stronger logic available will be more apparent. A smarter Semantic Web.

    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. So it seems to me that the easiest path for mass adoption of OWL is via RDF, which is why I find some the increased distance from RDF to OWL 1.1 a little troublesome.

    I've only skimmed the DIG 2.0 docs, but it does seem capable. Unfortunately its approach to HTTP seems painfully ignorant of current best practice. Aside from that, even if it were cleaned up in respect of WebArch and properly leveraged the benefits of HTTP, there would still be a very strong case for SPARQL, in that it's not rocket science (looking and behaving like simple SQL helps) and it covers a very large proportion of practical use case on today's web. (Incidentally, when I next have some free time I'm hoping to see how far I can get with using RDF+SPARQL for a simple agent framework, the DIG material should help a lot).

    I guess my basic points are that although OWL (+DIG) may have significant technical advantages in various areas, RDF (+SPARQL) is closer to the 80/20 coverage needed now - and that RDF is closer to OWL than the current web semantics, so there's a good adoption path. The web is only just learning how to rub sticks together to get fire, not sure there's much demand for nuclear power yet, no matter how clean.
    • ^
    • v
    Maybe the point isn’t that OWL is unreal but that it’s hard?

    I'm not convinced that OWL itself is actually that hard. This could be because I have a maths background, and don't have any IT baggage that means I have to learn a whole new paradigm. The hard part for me is the actual knowledge modeling when it comes to writing complex domain ontologies. Often domain experts in a field like geography tend to think in the vernacular and it can be quite hard identify which concepts really exist and how they relate to each other. I think once you have a good knowledge model in place it is reasonably straight forward to convert it to OWL [1]. The main difficulty arises when trying to create botches or approximations for things OWL cannot handle.

    [1] no doubt I'm going to regret claiming that at some point :)
    • ^
    • v
    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.
    • ^
    • v
    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! :)
    • ^
    • v
    Hi Kendall, thanks for the response.

    I've just re-read what I've written below, and I'm afraid it does seem rather confrontational. I'm really not trying to have a go, the main thing is that I've not really been particularly reassured by recent talk about the direction of OWL 1.1 in regard to RDF - in fact it's almost been "The lady doth protest too much, methinks".

    Ok, first of all I'll reaffirm what I said about the significance of the Web. The Web is essentially a public entity (even if areas are covered by significant access controls). It doesn't matter that you're using HTTP etc, if it's not connected to the outside world, it's not the Web. In the past these kinds of setup were known as Intranets. I don't see that moving up the layer cake changes that.

    I am not saying these things aren't interesting or useful or valuable. These are absolutely good applications of the technologies, but it's specious to suggest their requirements are also requirements of the Semantic Web, when the systems are in effect being used offline. I personally believe that OWL (including DL) has the potential for being extremely useful on the Web. But the way to get it there is not to extend it away from the material that's already starting to gain significant adoption (i.e. RDF).

    Oh, but this isn't moving away from RDF, right? How about: "Not every OWL 1.1 ontology can be serialized in RDF". I don't personally care much about the concrete syntax, that seems a bit of a red herring (in an ideal world I'd like to have seen a more XML-tool-friendly RDF/XML, but that seems unlikely to happen). What bothers me is having data that purports to be built on the Semantic web stack, yet is logically incompatible with the layers beneath it. Bijan's "nothing wrong with a new human-readable syntax" response doesn't really satisfy that point. I've not spent nearly enough time looking at OWL 1.1 to determine the implications for myself. The declaration of a mapping, when that mapping isn't actually 1:1 doesn't help much either - pretty much anything can be mapped to anything else if you miss bits out.

    I accept your point on protocols regarding DIG 2.0 vs SPARQL. The SPARQL protocol is short on features compared to DIG. I will note that many more operations are available than those made explicit in the specs - for example, a TELL-like operation is possible using a HTTP PUT with an RDF document as payload. It seems to me what's lacking is a formalisation of conventions for these (the 'spirit' of DIG), the lower-level protocols already being in place. In the context of the Web, I do feel it makes sense to use HTTP as designed, rather than quasi-RPC through POST (using text/xml for heaven's sake).
    • ^
    • v
    I see Danny is back.

    RDF/XML doesn't encode all legal RDF graphs. I fail to see where OWL 1.1 is worse off.

    The OWL 1.1 Mapping to RDF is considerably less mature than the rest, and we know the rest isn't yet recommendation ready yet. That's why one should have a working group. I don't see that you've even begun to build a case that there is a serious problem here.

    As long as the cardinality of the sets are denumerable, you can always have a 1:1 mapping without missing any bits. So, any (denumerable) set can be mapped 1:1 to any other (denumerable) set without loss. These mappings are not necessarily useful. So, converage doesn't necessarily indicate utility.

    "Moving away" requires a determination of intent. We provided a mapping document which does a fair chunk of the work and I've as much said that this is part of the WGs job, as I understand it. Of course, it's for the WG to decide exactly what it is going to do.

    Finally, I find that "from the requirements of the Web" fallacy to be just that, a fallacy. There are real users with significant uses who would like additional expressivity in the Web Ontology Language. I do not see how adding that expressivity (and rationalizations) breaks any aspect of the Web. That there is significant intranet use does not mean that there is not significant Web use. And even if the features were only helpful intranetly, I fail to see why that is a problem. Intranet use can helpfully complement internet use. Just because information isn't universality available does not mean it should not be homogenuously presented. If anything, making intranet use of designed to be open protocols and formats further encourages their use and adoption, promotes the development of tools and experience, and makes transition from private to public easier.

    A final technical point: If you actually read the RDF mapping you'll see that currently two features "defeat the mapping". One of those features is annotations of axioms. That is, for example, if I have an axiom:

    A rdfs:subClassOf B


    I may want to say that that axiom was added by Bijan on May 5th. Given the standard and natural mapping of OWL to RDF, this requires making an assertion about one or more triples. The only mechanism currently available for that is reification. So it would be, in some sense, easy to add these features to the mapping, but it's questionable that it would be useful due to issues with RDF.

    Again, this would be a matter for the WG to decide what it could live with. But this is hardly an unknown difficulty.
    • ^
    • v
    Like I said, I think the concrete serialization is something of a red herring. I stand by the point that a primary consideration for a Web Ontology Language should be the Web - taking precedence over non-Web use. I would certainly expect any group chartered at the W3C to bear that in mind. My concern is, as you've summarised nicely, that the specific changes break the (Semantic) Web. If they don't, and they're valuable to users, then great - let's have them. I wouldn't personally care if they were arbitrary additions that no-one used outside the firewall.

    I've been trying to think of a possible test for what might reasonably be considered breaking the web in this context. The best I can come up with so far is as follows :

    Take two OWL 1.1 documents, which when merged are consistent. Take one of them, and follow the mapping to express it (as far as is possible) in RDF. Map the RDF back to OWL 1.1, and merge. Will the result still be consistent for all original documents?
    (It'd be interesting to look in the other direction too, starting with two RDF graphs, but I'm not entirely sure what might work for a pass/fail there).
    • ^
    • v
    Danny,

    I'm glad to finally see a concrete question. Putting aside whether I agree that this is a criterion for "non-web breakage", I can answer this:

    "Yes". Consistency is fairly easy to assure when dropping functionality (in a monotonic system). Now, if you drop a feature, inconsistent documents might go consistent, but that's true now. There are inconsistent RDFS documents which are consistent RDF documents.
    • ^
    • v
    Thanks Bijan. I don't know about the suitably of this as a criterion either, but I think the general style of the question works (it's testable, and could be formalised). Either way, I find your mention of monotonicity reassuring.
 

Trackbacks

(Trackback URL)

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus