5 Best Semantic Web Tools

by Kendall Clark

Most people who read this weblog—all 4 of them!—are probably interested, at least a little bit, in concrete ways to get into the Semantic Web, so I thought I’d offer a list of the 5 Best Semantic Web Tools.

Note: “best” means, really, “most interesting or most ready to be thrown into production” and “tools” means, really, “tools, or libraries, or frameworks, or infrastructure pieces”.

The list is based on my experience, opinions about what matters most, and some subjective judgment about software quality, including my preference for open source software. This list isn’t even particularly objective or fair, since some of this software was written by friends and colleagues.

In short, I have a dog in this fight.

  1. Semantic Web Framework: Sesame

    I hate Java. I mean, I really really hate it. But, for good or bad, Java is the SemWeb implementation language choice, with (probably) Python a distant second. The very best soup-to-nuts Java framework for building SemWeb applications is Sesame, which is well-designed and implemented, tracks the relevant standards closely, and includes a nice spread of tools, from RDF databases, to OWL reasoners, to rule engines.

    Alternatives: Redland; for the Mono/.NET crowd there’s SemWeb.


  2. OWL Ontology Editor/IDE: SWOOP

    Building an OWL ontology can be a really useful thing to do, so it’s a good thing it’s not easy! Seriously, domain modeling by way of OWL ontologies is often the Right Thing to Do, but it’s often not trivial. So there are a raft of OWL editors that aim to make it easier to build OWL ontologies. (Check this weblog in the next few weeks for a post about why and when OWL makes sense. I think, in the near to medium term, OWL has a bright future as a general purpose policy language; and, thus, OWL reasoners may become general purpose policy engines.)

    SWOOP is a Java app, but uses as many web browser metaphors as possible, in an attempt to make ontology development as painless as possible. It’s well-integrated with Pellet, about which more below, which it uses as its OWL reasoner. SWOOP allows you to edit ontologies, create new ones, and to do so collaboratively with others by using the the Annotea protocol—you can share ontology “change sets” over the Web to members of your development group. Which is very cool.

    SWOOP also has world-class support for OWL, including species validation (what kind of logic is your ontology?), querying ontologies using RDQL, as well as one-of-a-kind ontology partioning and debugging.


    (Because of the frequent claims, on places like the Slashdot Forums, that the idea of the Semantic Web requires “one big ontology”, which everyone has to conform to… Well, because this claim is just so wrong, I want to say more about SWOOP’s partitioning support. What does it mean that SWOOP can automatically partition your ontology? Well, it means that SWOOP knows algorithms for breaking apart your domain modeling into distinct models of subdomains. Throw it a giant, cross-domain ontology like NCI’s cancer ontology—which knows about everything from genes to proteins to charbroiled meat (seriously!)—and SWOOP will partition it into more manageable, equivalent ontologies (there are many devils in the details, including some ontologies that SWOOP can’t partition, but, trust me, partitioning is uber-cool). That makes reasoning over them easier, it is likely to make OWL reasoning more scalable in the future, and it also means that the Semantic Web does not require “one big ontology”.)


    SWOOP’s ontology debugging and visualization tools may be even cooler than its partition magic, and I’ll try to post more about them in the near future. In repeated end-user usability tests, SWOOP’s debugging facilities have been proven to make it easier to diagnose and repair a broken ontology than to do so in an ontology editor without debugging support.


    SWOOP is a must-have tool if you have to do anything with OWL.


    Alternatives: Protege-2000.

  3. OWL Reasoner: Pellet

    Pellet, an OWL-DL reasoner written in Java, isn’t the fastest OWL reasoner, but it’s probably the fastest open source OWL reasoner and it’s certainly one of the most feature-rich OWL reasoners.


    Alternatives: Cerebra, RacerPRO, FaCT++


  4. RDF Database: Kowari

    I’ll have more to say about this category later, but this is still a wide-open space, in my mind, that the right startup could fill nicely.


    Alternatives: Sesame-MySQL, 3Store, Oracle RDF, ...

  5. SPARQL Front End: XML Army Knife’s SPARQL Query Form
Spread the word:
  • Reddit
  • Digg
  • del.icio.us
  • TwitThis
  • Technorati

61 Responses to “5 Best Semantic Web Tools”

  1. Bijan Says:

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

    I’m not a huge Kowari fan…no RDFS and it seems a bit of a PITA to get working. Another category that could be interesting is “lightweight, simple” RDF stores. I.e., for small projects where you just want to read in an RDF/XML file process it, and dump something.

  2. Bijan Says:

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

    I’m not a huge Kowari fan…no RDFS and it seems a bit of a PITA to get working. Another category that could be interesting is “lightweight, simple” RDF stores. I.e., for small projects where you just want to read in an RDF/XML file process it, and dump something.

  3. Bijan Says:

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

    I’m not a huge Kowari fan…no RDFS and it seems a bit of a PITA to get working. Another category that could be interesting is “lightweight, simple” RDF stores. I.e., for small projects where you just want to read in an RDF/XML file process it, and dump something.

  4. Bijan Says:

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

    I’m not a huge Kowari fan…no RDFS and it seems a bit of a PITA to get working. Another category that could be interesting is “lightweight, simple” RDF stores. I.e., for small projects where you just want to read in an RDF/XML file process it, and dump something.

  5. Bijan Says:

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

    I’m not a huge Kowari fan…no RDFS and it seems a bit of a PITA to get working. Another category that could be interesting is “lightweight, simple” RDF stores. I.e., for small projects where you just want to read in an RDF/XML file process it, and dump something.

  6. Kendall Says:

    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.

  7. Kendall Says:

    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.

  8. Kendall Says:

    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.

  9. Kendall Says:

    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.

  10. Kendall Says:

    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.

  11. Dave Beckett Says:

    Clearly I have an interest in this too :) but more interesting would be expansions on why you might choose a particular OWL reasoner as “best”. From what I’ve read and heard so far, they all emphasise different things, do different sub/supersets of different OWL layers so comparison is rather multi-dimensional.
    Do you really mean to say Pellet is the “most … proprietary” or did I read that wrong? Pellet’s the best RDFS and OWL editor for me.
    Jena seems a strong peer of Sesame but isn’t mentioned at all.
    Maybe you could say what Java systems are below Pellet, SWOOP and the SPARQL frontend?

  12. Dave Beckett Says:

    Clearly I have an interest in this too :) but more interesting would be expansions on why you might choose a particular OWL reasoner as “best”. From what I’ve read and heard so far, they all emphasise different things, do different sub/supersets of different OWL layers so comparison is rather multi-dimensional.
    Do you really mean to say Pellet is the “most … proprietary” or did I read that wrong? Pellet’s the best RDFS and OWL editor for me.
    Jena seems a strong peer of Sesame but isn’t mentioned at all.
    Maybe you could say what Java systems are below Pellet, SWOOP and the SPARQL frontend?

  13. Dave Beckett Says:

    Clearly I have an interest in this too :) but more interesting would be expansions on why you might choose a particular OWL reasoner as “best”. From what I’ve read and heard so far, they all emphasise different things, do different sub/supersets of different OWL layers so comparison is rather multi-dimensional.
    Do you really mean to say Pellet is the “most … proprietary” or did I read that wrong? Pellet’s the best RDFS and OWL editor for me.
    Jena seems a strong peer of Sesame but isn’t mentioned at all.
    Maybe you could say what Java systems are below Pellet, SWOOP and the SPARQL frontend?

  14. Dave Beckett Says:

    Clearly I have an interest in this too :) but more interesting would be expansions on why you might choose a particular OWL reasoner as “best”. From what I’ve read and heard so far, they all emphasise different things, do different sub/supersets of different OWL layers so comparison is rather multi-dimensional.
    Do you really mean to say Pellet is the “most … proprietary” or did I read that wrong? Pellet’s the best RDFS and OWL editor for me.
    Jena seems a strong peer of Sesame but isn’t mentioned at all.
    Maybe you could say what Java systems are below Pellet, SWOOP and the SPARQL frontend?

  15. Dave Beckett Says:

    Clearly I have an interest in this too :) but more interesting would be expansions on why you might choose a particular OWL reasoner as “best”. From what I’ve read and heard so far, they all emphasise different things, do different sub/supersets of different OWL layers so comparison is rather multi-dimensional.
    Do you really mean to say Pellet is the “most … proprietary” or did I read that wrong? Pellet’s the best RDFS and OWL editor for me.
    Jena seems a strong peer of Sesame but isn’t mentioned at all.
    Maybe you could say what Java systems are below Pellet, SWOOP and the SPARQL frontend?

  16. Bijan Says:

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

    I’m not a huge Kowari fan…no RDFS and it seems a bit of a PITA to get working. Another category that could be interesting is “lightweight, simple” RDF stores. I.e., for small projects where you just want to read in an RDF/XML file process it, and dump something.

  17. Kendall Says:

    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.

  18. Dave Beckett Says:

    Clearly I have an interest in this too :) but more interesting would be expansions on why you might choose a particular OWL reasoner as “best”. From what I’ve read and heard so far, they all emphasise different things, do different sub/supersets of different OWL layers so comparison is rather multi-dimensional.
    Do you really mean to say Pellet is the “most … proprietary” or did I read that wrong? Pellet’s the best RDFS and OWL editor for me.
    Jena seems a strong peer of Sesame but isn’t mentioned at all.
    Maybe you could say what Java systems are below Pellet, SWOOP and the SPARQL frontend?

  19. Kendall Says:

    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.

  20. Kendall Says:

    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.

  21. Kendall Says:

    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.

  22. Kendall Says:

    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.

  23. Kendall Says:

    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.

  24. Kendall Says:

    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.

  25. Ian Dickinson Says:

    “choose Sesame 10 times out of 10” because …. ?

    Serious question. Not least because we’ve heard the opposite opinion (people who’ve had better experiences building their apps with Jena than Sesame), so there are clearly some sets of criteria that indicate either tool for some user applications. If your interest is in helping semantic web developers make appropriate choices of tools then making your criteria clear would be helpful. Being broad, open source and tracking the standards, the only objective criteria you mention, don’t differentiate Jena and Sesame. More generally, it just seems a bit lame to make absolute subjective recommendations without at least some supporting evidence.

    Ian (declaration: member of the Jena team)

  26. Ian Dickinson Says:

    “choose Sesame 10 times out of 10” because …. ?

    Serious question. Not least because we’ve heard the opposite opinion (people who’ve had better experiences building their apps with Jena than Sesame), so there are clearly some sets of criteria that indicate either tool for some user applications. If your interest is in helping semantic web developers make appropriate choices of tools then making your criteria clear would be helpful. Being broad, open source and tracking the standards, the only objective criteria you mention, don’t differentiate Jena and Sesame. More generally, it just seems a bit lame to make absolute subjective recommendations without at least some supporting evidence.

    Ian (declaration: member of the Jena team)

  27. Ian Dickinson Says:

    “choose Sesame 10 times out of 10” because …. ?

    Serious question. Not least because we’ve heard the opposite opinion (people who’ve had better experiences building their apps with Jena than Sesame), so there are clearly some sets of criteria that indicate either tool for some user applications. If your interest is in helping semantic web developers make appropriate choices of tools then making your criteria clear would be helpful. Being broad, open source and tracking the standards, the only objective criteria you mention, don’t differentiate Jena and Sesame. More generally, it just seems a bit lame to make absolute subjective recommendations without at least some supporting evidence.

    Ian (declaration: member of the Jena team)

  28. Ian Dickinson Says:

    “choose Sesame 10 times out of 10” because …. ?

    Serious question. Not least because we’ve heard the opposite opinion (people who’ve had better experiences building their apps with Jena than Sesame), so there are clearly some sets of criteria that indicate either tool for some user applications. If your interest is in helping semantic web developers make appropriate choices of tools then making your criteria clear would be helpful. Being broad, open source and tracking the standards, the only objective criteria you mention, don’t differentiate Jena and Sesame. More generally, it just seems a bit lame to make absolute subjective recommendations without at least some supporting evidence.

    Ian (declaration: member of the Jena team)

  29. Ian Dickinson Says:

    “choose Sesame 10 times out of 10” because …. ?

    Serious question. Not least because we’ve heard the opposite opinion (people who’ve had better experiences building their apps with Jena than Sesame), so there are clearly some sets of criteria that indicate either tool for some user applications. If your interest is in helping semantic web developers make appropriate choices of tools then making your criteria clear would be helpful. Being broad, open source and tracking the standards, the only objective criteria you mention, don’t differentiate Jena and Sesame. More generally, it just seems a bit lame to make absolute subjective recommendations without at least some supporting evidence.

    Ian (declaration: member of the Jena team)

  30. Ian Dickinson Says:

    “choose Sesame 10 times out of 10” because …. ?

    Serious question. Not least because we’ve heard the opposite opinion (people who’ve had better experiences building their apps with Jena than Sesame), so there are clearly some sets of criteria that indicate either tool for some user applications. If your interest is in helping semantic web developers make appropriate choices of tools then making your criteria clear would be helpful. Being broad, open source and tracking the standards, the only objective criteria you mention, don’t differentiate Jena and Sesame. More generally, it just seems a bit lame to make absolute subjective recommendations without at least some supporting evidence.

    Ian (declaration: member of the Jena team)

  31. Maggie Says:

    I’m also interested in why you prefer Sesame, mostly because you also recommend Pellet and talk about SPARQL. I’m new to semantic web work and have been trying to determine whether to try Sesame or Jena for my project. I’ve heard good things about Sesame, but Pellet works with Jena, and Sesame’s stable version doesn’t support SPARQL.

    Is there a good OWL-reasoning store for Sesame? (Do you have a recommendation?) Is it annoying to have to use SerQL (or is Sesame 2.0 stable enough to get things done?)

  32. Maggie Says:

    I’m also interested in why you prefer Sesame, mostly because you also recommend Pellet and talk about SPARQL. I’m new to semantic web work and have been trying to determine whether to try Sesame or Jena for my project. I’ve heard good things about Sesame, but Pellet works with Jena, and Sesame’s stable version doesn’t support SPARQL.

    Is there a good OWL-reasoning store for Sesame? (Do you have a recommendation?) Is it annoying to have to use SerQL (or is Sesame 2.0 stable enough to get things done?)

  33. Maggie Says:

    I’m also interested in why you prefer Sesame, mostly because you also recommend Pellet and talk about SPARQL. I’m new to semantic web work and have been trying to determine whether to try Sesame or Jena for my project. I’ve heard good things about Sesame, but Pellet works with Jena, and Sesame’s stable version doesn’t support SPARQL.

    Is there a good OWL-reasoning store for Sesame? (Do you have a recommendation?) Is it annoying to have to use SerQL (or is Sesame 2.0 stable enough to get things done?)

  34. Maggie Says:

    I’m also interested in why you prefer Sesame, mostly because you also recommend Pellet and talk about SPARQL. I’m new to semantic web work and have been trying to determine whether to try Sesame or Jena for my project. I’ve heard good things about Sesame, but Pellet works with Jena, and Sesame’s stable version doesn’t support SPARQL.

    Is there a good OWL-reasoning store for Sesame? (Do you have a recommendation?) Is it annoying to have to use SerQL (or is Sesame 2.0 stable enough to get things done?)

  35. Maggie Says:

    I’m also interested in why you prefer Sesame, mostly because you also recommend Pellet and talk about SPARQL. I’m new to semantic web work and have been trying to determine whether to try Sesame or Jena for my project. I’ve heard good things about Sesame, but Pellet works with Jena, and Sesame’s stable version doesn’t support SPARQL.

    Is there a good OWL-reasoning store for Sesame? (Do you have a recommendation?) Is it annoying to have to use SerQL (or is Sesame 2.0 stable enough to get things done?)

  36. Kendall Says:

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

  37. Kendall Says:

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

  38. Kendall Says:

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

  39. Kendall Says:

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

  40. Kendall Says:

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

  41. Maggie Says:

    I’m also interested in why you prefer Sesame, mostly because you also recommend Pellet and talk about SPARQL. I’m new to semantic web work and have been trying to determine whether to try Sesame or Jena for my project. I’ve heard good things about Sesame, but Pellet works with Jena, and Sesame’s stable version doesn’t support SPARQL.

    Is there a good OWL-reasoning store for Sesame? (Do you have a recommendation?) Is it annoying to have to use SerQL (or is Sesame 2.0 stable enough to get things done?)

  42. Kendall Says:

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

  43. Matt Williams Says:

    Interesting article…I’d heard a bit about Sesame, but will go and have a look.

    Agree about Kowari, both that it’s good, and a REAL PITA to get running (all the docs are out of date wrt packages, so even running the examples breaks….).

    Also agree about Pellet, which is great. AFAIK, FACT++ is only OWL-Lite, whereas Pellet is OWL-DL plus cardinality. Others (like RACER) lose out due to the closed source/ ‘license your kidneys to use the software’ approach.

    I’d choose Protege over SWOOP any day…

    Just my penny’s worth,
    Matt

  44. Matt Williams Says:

    Interesting article…I’d heard a bit about Sesame, but will go and have a look.

    Agree about Kowari, both that it’s good, and a REAL PITA to get running (all the docs are out of date wrt packages, so even running the examples breaks….).

    Also agree about Pellet, which is great. AFAIK, FACT++ is only OWL-Lite, whereas Pellet is OWL-DL plus cardinality. Others (like RACER) lose out due to the closed source/ ‘license your kidneys to use the software’ approach.

    I’d choose Protege over SWOOP any day…

    Just my penny’s worth,
    Matt

  45. Matt Williams Says:

    Interesting article…I’d heard a bit about Sesame, but will go and have a look.

    Agree about Kowari, both that it’s good, and a REAL PITA to get running (all the docs are out of date wrt packages, so even running the examples breaks….).

    Also agree about Pellet, which is great. AFAIK, FACT++ is only OWL-Lite, whereas Pellet is OWL-DL plus cardinality. Others (like RACER) lose out due to the closed source/ ‘license your kidneys to use the software’ approach.

    I’d choose Protege over SWOOP any day…

    Just my penny’s worth,
    Matt

  46. Matt Williams Says:

    Interesting article…I’d heard a bit about Sesame, but will go and have a look.

    Agree about Kowari, both that it’s good, and a REAL PITA to get running (all the docs are out of date wrt packages, so even running the examples breaks….).

    Also agree about Pellet, which is great. AFAIK, FACT++ is only OWL-Lite, whereas Pellet is OWL-DL plus cardinality. Others (like RACER) lose out due to the closed source/ ‘license your kidneys to use the software’ approach.

    I’d choose Protege over SWOOP any day…

    Just my penny’s worth,
    Matt

  47. Matt Williams Says:

    Interesting article…I’d heard a bit about Sesame, but will go and have a look.

    Agree about Kowari, both that it’s good, and a REAL PITA to get running (all the docs are out of date wrt packages, so even running the examples breaks….).

    Also agree about Pellet, which is great. AFAIK, FACT++ is only OWL-Lite, whereas Pellet is OWL-DL plus cardinality. Others (like RACER) lose out due to the closed source/ ‘license your kidneys to use the software’ approach.

    I’d choose Protege over SWOOP any day…

    Just my penny’s worth,
    Matt

  48. Matt Williams Says:

    Interesting article…I’d heard a bit about Sesame, but will go and have a look.

    Agree about Kowari, both that it’s good, and a REAL PITA to get running (all the docs are out of date wrt packages, so even running the examples breaks….).

    Also agree about Pellet, which is great. AFAIK, FACT++ is only OWL-Lite, whereas Pellet is OWL-DL plus cardinality. Others (like RACER) lose out due to the closed source/ ‘license your kidneys to use the software’ approach.

    I’d choose Protege over SWOOP any day…

    Just my penny’s worth,
    Matt

  49. Bijan Parsia Says:

    FaCT++ is actually now all of SHOIN, thus (depending on datatype support) all of OWL-DL. It’s ABox support is weak though and it doesn’t (yet) have any optimizations for nominals.

    Pellet does not (yet) support qualified cardinality, alas. Soon we hope. Pellet does support nominals with a lot of optimizations and nice ABox support (including conjunctive query). Not to mention all the debugging features (though some of them are reasoner independent).

    Re: Protege over SWOOP…what can I say, when you’re wrong you’re wrong ;)

    Ok, I hate using Protege and and a main force behind Swoop, so I’m biased. If we can get Swoop stable, I think both the functionality and the usability blow Protege out of the water. (For OWL, at least.)

  50. Bijan Parsia Says:

    FaCT++ is actually now all of SHOIN, thus (depending on datatype support) all of OWL-DL. It’s ABox support is weak though and it doesn’t (yet) have any optimizations for nominals.

    Pellet does not (yet) support qualified cardinality, alas. Soon we hope. Pellet does support nominals with a lot of optimizations and nice ABox support (including conjunctive query). Not to mention all the debugging features (though some of them are reasoner independent).

    Re: Protege over SWOOP…what can I say, when you’re wrong you’re wrong ;)

    Ok, I hate using Protege and and a main force behind Swoop, so I’m biased. If we can get Swoop stable, I think both the functionality and the usability blow Protege out of the water. (For OWL, at least.)

  51. Bijan Parsia Says:

    FaCT++ is actually now all of SHOIN, thus (depending on datatype support) all of OWL-DL. It’s ABox support is weak though and it doesn’t (yet) have any optimizations for nominals.

    Pellet does not (yet) support qualified cardinality, alas. Soon we hope. Pellet does support nominals with a lot of optimizations and nice ABox support (including conjunctive query). Not to mention all the debugging features (though some of them are reasoner independent).

    Re: Protege over SWOOP…what can I say, when you’re wrong you’re wrong ;)

    Ok, I hate using Protege and and a main force behind Swoop, so I’m biased. If we can get Swoop stable, I think both the functionality and the usability blow Protege out of the water. (For OWL, at least.)

  52. Bijan Parsia Says:

    FaCT++ is actually now all of SHOIN, thus (depending on datatype support) all of OWL-DL. It’s ABox support is weak though and it doesn’t (yet) have any optimizations for nominals.

    Pellet does not (yet) support qualified cardinality, alas. Soon we hope. Pellet does support nominals with a lot of optimizations and nice ABox support (including conjunctive query). Not to mention all the debugging features (though some of them are reasoner independent).

    Re: Protege over SWOOP…what can I say, when you’re wrong you’re wrong ;)

    Ok, I hate using Protege and and a main force behind Swoop, so I’m biased. If we can get Swoop stable, I think both the functionality and the usability blow Protege out of the water. (For OWL, at least.)

  53. Bijan Parsia Says:

    FaCT++ is actually now all of SHOIN, thus (depending on datatype support) all of OWL-DL. It’s ABox support is weak though and it doesn’t (yet) have any optimizations for nominals.

    Pellet does not (yet) support qualified cardinality, alas. Soon we hope. Pellet does support nominals with a lot of optimizations and nice ABox support (including conjunctive query). Not to mention all the debugging features (though some of them are reasoner independent).

    Re: Protege over SWOOP…what can I say, when you’re wrong you’re wrong ;)

    Ok, I hate using Protege and and a main force behind Swoop, so I’m biased. If we can get Swoop stable, I think both the functionality and the usability blow Protege out of the water. (For OWL, at least.)

  54. Bijan Parsia Says:

    FaCT++ is actually now all of SHOIN, thus (depending on datatype support) all of OWL-DL. It’s ABox support is weak though and it doesn’t (yet) have any optimizations for nominals.

    Pellet does not (yet) support qualified cardinality, alas. Soon we hope. Pellet does support nominals with a lot of optimizations and nice ABox support (including conjunctive query). Not to mention all the debugging features (though some of them are reasoner independent).

    Re: Protege over SWOOP…what can I say, when you’re wrong you’re wrong ;)

    Ok, I hate using Protege and and a main force behind Swoop, so I’m biased. If we can get Swoop stable, I think both the functionality and the usability blow Protege out of the water. (For OWL, at least.)

  55. zzpaul Says:

    Hi, I am a beginner on ontology/semantic web. I have tried using Protege. I found it pretty good. It is quite easy to learn and use and I like the OntViz that displays an ontology graphically.

    For SWOOP, I can’t find any tutorial on it. It makes me hard to learn. Do you all know where can I find some tutorials on it? Thank you!

  56. zzpaul Says:

    Hi, I am a beginner on ontology/semantic web. I have tried using Protege. I found it pretty good. It is quite easy to learn and use and I like the OntViz that displays an ontology graphically.

    For SWOOP, I can’t find any tutorial on it. It makes me hard to learn. Do you all know where can I find some tutorials on it? Thank you!

  57. zzpaul Says:

    Hi, I am a beginner on ontology/semantic web. I have tried using Protege. I found it pretty good. It is quite easy to learn and use and I like the OntViz that displays an ontology graphically.

    For SWOOP, I can’t find any tutorial on it. It makes me hard to learn. Do you all know where can I find some tutorials on it? Thank you!

  58. zzpaul Says:

    Hi, I am a beginner on ontology/semantic web. I have tried using Protege. I found it pretty good. It is quite easy to learn and use and I like the OntViz that displays an ontology graphically.

    For SWOOP, I can’t find any tutorial on it. It makes me hard to learn. Do you all know where can I find some tutorials on it? Thank you!

  59. zzpaul Says:

    Hi, I am a beginner on ontology/semantic web. I have tried using Protege. I found it pretty good. It is quite easy to learn and use and I like the OntViz that displays an ontology graphically.

    For SWOOP, I can’t find any tutorial on it. It makes me hard to learn. Do you all know where can I find some tutorials on it? Thank you!

  60. zzpaul Says:

    Hi, I am a beginner on ontology/semantic web. I have tried using Protege. I found it pretty good. It is quite easy to learn and use and I like the OntViz that displays an ontology graphically.

    For SWOOP, I can’t find any tutorial on it. It makes me hard to learn. Do you all know where can I find some tutorials on it? Thank you!

  61. Bijan Parsia Says:

    zzpaul,

    You might look at some of the demo demo movies which, while quite old, should give you some idea.

    Cheers,
    Bijan.

Leave a Reply