Hallo Kendall, I am not a core rdflib developer at all so please take my comments as something coming from someone in a perhaps similar position as yours: just trying and using rdflib and constantly evaluating it against other python alternatives.
I started using it at a time when redland was core dumping just a little too often to be nearly any useful, but I have not nailed into my head the idea that redland is total crap, quite the opposite, it may have simply needed some more man-hours poured into it, and I think rdflib is probably in a similar situation under many aspects, some of which you have highlighted, but for sure it ain't core dumping ;-) Kendall Clark ha scritto: [...] > (FWIW: Sparta's use of OWL cardinality constraints is *completely* > broken. OWL cardinality constraints are *not* database constraints, at > all, but that's how Sparta uses and describes them. Which just *spreads > confusion*. That's just broken by design. Nothing prevennts anyone from > doing database constraints, but those properties should *not* be in the > OWL namespace. Database integrity constraints are a *very* good thing, > but that's *not* what OWL max cardinality is about.) [...] I am not very familiar with Sparta and not at all with how it uses cardinality constraints but I found your point here particularly interesting because I am experimenting with something similar to an OWL-based python data binding tool. I am doing useful things with it (and I hope I can polish it and release it soon) but I am in no way using OWL cardinality. It is more useful and less confusing to acknowledge that OWL is a good subset of what a really useful and easy constraints-describing language should be and I think it can be argued that it is a lot better to this regard than a lot of the alternatives normally considered by app designers who are aware of the web's ever-growing diversity (it is called web ontology language after all, isn't it?). Adding a new standard RDF-based language for expressing constraints at the semantic level, or even worse, wait that people roll their own attempts at such a thing in their apps (and motivating this simply because OWL "is not about" constraints at all, depicting it as a no-go by design) would add to the confusion, generating a constraint-soup situation, similar to what tag-soup has been in the past with respect to syntax. While I don't see this danger if people try building their own attempts on top of a nice, already quite powerful (even if not fully satisfying yet) and standard language for expressing, ahem, very similar concepts to a constraint. After all, discrimination of semantics (on the web and beyond) is what OWL and the OWL community are all about so why worry at all if OWL semantics themselves are being used in ways that stimulate further discrimination? It might do them good. The main misunderstanding seems to be that using it for "constraining" should actually be better defined, experimented and discussed, its relationship with "inconsistency checking" should be more clearly stated. I have found the following resources very useful and clear in daring experimenting this path: 1) these slides: <http://www.idealliance.org/proceedings/xtech05/slides/steer/Owl%20Profiles%20and%20Forms.pdf> Sorry, this seems to exist in PDF-only form with no homepage, I hate that too, but the slides are very self-explanatory and the overview of advantages and gotchas of such an approach are made very clear, even that maxcardinality should be not be used for that, which seems your main point against this. In particular (this answers also to Chimezie's answer) it says you don't necessarily need a reasoner to get away with useful results when you are mostly interested in instance reasoning rather than class reasoning. 2) this thread, all of it, but I like a citation from this mail in particular: <http://lists.w3.org/Archives/Public/semantic-web/2006Apr/0154.html> "assuming [the user] is fully aware of what's going on, no awful sin has been committed" It is clear that easy consensus over this very specific topic is not quite there even among top experts, still it seems much easier to acheive that through further experimentation and better documentation than it would be by explaining people that thinking at OWL as a contraint-expressing language is wrong by design, the latter conclusion seems rather based on assumptions that are or should be necessarily questionable in the OWL ecosystem i.e. stating that you are using closed-world reasoning instead of open-world reasoning in a specific part of your app is not necessarily defeating OWL's purpose, quite the opposite. 3) this official W3C note: <http://www.w3.org/TR/sw-oosd-primer/> The fact that it exists can be read as proof that people trying to use OWL in that way are considered to be a growing number, not a diminishing one so it seems wise to be prepared for discussion and options, not for tout-court refusal of the approach that seems more natural to that many people who probably share most of the same goals as the OWL designers had. This said, it is worth stating also that I am not at all against a differentiation of layers in RDF APIs, I do agree 100% that sparta-like functionality does not belong to the very core of an RDF lib, yet I would like it if it was an option made easily available. Reasoning should be a further orthogonal layer. The combined API, featuring core+reasoning+databinding functionality promises indeed to be very powerful but can be hardly acheived with an all-or-nothing approach. This seems a good moment for apologizing for having written so much in my answer, and for reiterating that I am by no means an rdflib nor logic theory and neither an OWL authority: I am just loving to use all of them toghether to solve very basic and concrete web interface (XForms) generation and databinding problems, instead of starting to invent from scratch or falling back to some syntax-only approach. Thanks for reading so far and most importantly for having kickstarted such an interesting discussion, ciao ste _______________________________________________ Dev mailing list [email protected] http://rdflib.net/mailman/listinfo/dev
