Re: Intersection of properties?

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. 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. 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.
> 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 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. When I am building "real" ontologies 
I stick to presuming that I will only try and say what I know I can say 
in OWL to avoid making them unnecessarily complicated to get an 
inference that may not even be possible, and reduce the chance on 
inconsistency and reasoning time.

>> This too is a lot of effort on the users part, especially if the end 
>> result is just being told that it is not possible for one reason or 
>> another.
> 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.

This intersection of properties example is a great example - as now I am 
aware of it, I can look out for it.

As for publications, well, when you are working in a domain like the 
Life Sciences, you get life science publications if you do some 
interesting biology with whatever new technology you have been playing 
with, and messing about with the technology itself doesn't really get 
you many points. I assure you that I am familiar with this frustration.

>> Going out on a limb here - and I dont expect this will happen - but I 
>> dont see why OWL-Full can't be furnished with the appropriate syntax 
>> for *potential* expressivity like role conjunction so that people 
>> will a) know what extentions are theoretically possible and therefore 
>> be able to ask for them and b) be able to play around with them 
>> (albeit only syntactiacally) and generate the kinds of use cases that 
>> you and the working group are looking for, possibly even with tool 
>> support for the process.
> 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. 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.

First Order is easy, ill try and remember that.

Cheers
Andrew

Received on Monday, 4 August 2008 13:31:20 UTC