- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Mon, 4 Aug 2008 16:45:33 +0100
- To: Andrew Gibson <a.p.gibson@uva.nl>
- Cc: public-owl-dev@w3.org
On 4 Aug 2008, at 10:57, Andrew Gibson wrote: > It seems my original email to the list has gone missing in the > ether somewhere, and so some of my original point(s) have been lost > in the edits here, so I shall try and clarify what I was getting at. >>> I think that it is hard to gauge demand for currently unsupported >>> expressivity in OWL, as there is no "big list" of expressivity >>> features of different languages from which non-logicians could >>> say "hey that would be really useful in OWL". >> Rules, Description Graphs, temporal and spatial features, linear >> and arbitrary polynomials.... > The emphasis should be on 'non-logicians' in my original statement. These are all requested by non-logicians. The specific flavor is where things get tricky. > I am aware of most of those areas of research, that they can be > applied to specific types of problem, and that they aren't likely > to be added to OWL, but that isn't what I meant. ? They aren't? > The ISWC paper that you sent out a link to had a very clear example > in the introduction about a spam filter - with a specific type of > inference associated with it. All elephants are bigger than all > mice is another nice clear example. My point was that if I could > see the 'menu' of specific inferences that it is possible to > achieve through one logic or another, then I would be better placed > to ask for these features, and with clearer use cases. Sure, but chicken and egg. A lot of use cases come, naturally, from people trying to model things. Not every user can do that, but, frankly, those who can have a useful skill and, naturally, greater leverage. >> Ok, it's not a huge list, but someone explicitly requesting >> property intersection presumably has a concrete need. > I wouldn't rely on that presumption I don't know what you mean by "rely", but it's certainly reasonable and makes it even more reasonable for me to ask. If they can't articulate a need even with interaction then, guess what, I'm not going to work toward that feature. I don't see how this is unreasonable or unwise...it's not like the list of pending work is *near* empty :) > - I have discovered things I cant say in OWL and that I think would > be useful to say whilst building test ontologies, because its > easier to see the consquences of certain combinations of axioms > over smaller models. As such these things usually crop up in > trivial examples for me. So? Send it along. Trivial examples are enough to get things on the page. [snip] >> I assure you that it is a tremendous amount of work on the >> implementor and spec folks too. It's rather frustrating to produce >> something that doesn't get used *and* doesn't get a publication. > I hope I didn't give the impression that i think that implementors > and specification people aren't working hard. I was trying to get > across that there could be more done to ensure negotiation of OWL > extensions. If it was clearer what I *could* say (without doing the > hard work of implementing it), then I would be better placed to > ascertain whether I *need* to say it. Of course. I don't know if we're disagreeing per se. I've long championed the need for prototypes in software for people to play with and I've also championed survey papers on features (for example) at OWLED. But *those* are a tremendous amount of work, too. > This intersection of properties example is a great example - as now > I am aware of it, I can look out for it. Well, intersection of properties (and other role constructors) are listed on the DL navigator. So I'd recommend looking there for inspiration. [snip] >> This just isn't a good idea. Especially at the standards level, >> it's quite mad to throw in more stuff on spec without an intention >> of impelmenting it. If you want to play with extensions, try one >> of the first order logic reasoners. Most everything we add is just >> more first order, so it's pretty easy, for some strange value of >> "easy", to experiment qua user. > Alright, this was just idle speculation really rather than a > serious suggestion. The point stands though, that If I can somehow > *see* the sorts of inferences that I *might* be able to achieve in > *some* logic, then I would be in a much better situation to rank my > requirements based on the sort of knowledge I have in my domain, > rather than the current Carte Blanche - ask for something and you > might get it system. I agree. > What i was getting at is if I had a syntax for saying these things, > then I could even construct concrete examples in code rather than > just hypothetical ones on paper, and this process could be > supported by tools. It's the "supported by tools" bit. It's really not so very easy. OTOH, there are some FOL xml syntaxes. > First Order is easy, ill try and remember that. Yep. Cheers, Bijan.
Received on Monday, 4 August 2008 15:43:22 UTC