Re: [ontolog-forum] Strange problem with cardinality restrictions

[Przemyslaw Jaskierski <przemjaskier@xxxxxxxxx>]

Hello, thank you for your replies.

 

It appears to me, from the Wine tutorial, that it does encourage this.  I just don't understand what you can do by having positive votes and negative votes be different types of things, rather than the same type of thing with a different attribute value.

I can see from the below that it surely adds complexity, this plethora of 'types'.

My example just shows model logically equivalent to much more complex one that I'm working on as a POC for logic programming with OWL.

I need to simply make a GOOD/BAD classification of an individual - based on the class types of 1..n of individuals connected to him by a hasX property. Making subclasses for this classification makes sense for me - I'm searching a solution for what looks like a trivial problem - making PositiveVoteResult and NegativeVoteResult separate classes changes nothing - NegativeVoteResult is set properly and PositiveVoteResult is never set for an individual that supposed to match the condition.

> OWL is a restricted subset of logic, and Protege is a tool.
> Neither one is useful for this problem.

Ok, but I have to use Protege/OWL here. I have an impression that it can be done, but I'm missing something trivial here. If one trivial cardinality restriction works good and another trivial (complementary/opposite???) restriction does not, maybe the solution is really simple? I mean, if such trivial thing can't be expressed there is something really bad with this technology...

Best regards,

Przemek

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (01)