Thankfully, I just found a paper that does a much better job than I did at presenting and preserving options while doing no harm to any approach:
<http://www.cs.man.ac.uk/~horrocks/Publications/download/2005/HoPa05a.pdf> It is going to take me some time to read and understand all of it so I already jumped to the conclusions, which are apparently confirming what I was trying to express but in a lot clearer way. Sorry again for the PDF link, it seems that even the RDF/OWL community is waiting for the semantic web instead of publishing their research using hypertext-based "traditional" web, which was actually invented exactly for publishing and sharing academic papers and making it easy to point at suchly "represented" concepts, if this is irony of destiny or a precise design requirement of academy we will find out only when semantic web will be there. ciao ste Stefano Debenedetti ha scritto: > 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 > _______________________________________________ Dev mailing list [email protected] http://rdflib.net/mailman/listinfo/dev
