ontolog-forum
[Top] [All Lists]

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

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: William Frank <williamf.frank@xxxxxxxxx>
Date: Mon, 10 Jun 2013 11:44:09 -0400
Message-id: <CALuUwtDx0c+4TQUb9vmfr97=xw8FFsLWo2HqQyK=duEDv8KQ4g@xxxxxxxxxxxxxx>


On Mon, Jun 10, 2013 at 4:51 AM, Przemyslaw Jaskierski <przemjaskier@xxxxxxxxx> wrote:
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

Even when the two subclasses 'Yes', 'No', are constants, and so naturally VAULES?? (I.e, are themselves individuals?)

After looking at some good models of similar things in OWL, I am now quite sure that this is not a good practice, just a bad practice that is becoming increasingly common.   Your answer below shows you want to create even more bogus classes.   I recommend you instead have a type 'Vote Response', and **associate*** vote response with 'vote", instead of subtyping 'vote'.  In other words, define a predicate (i.e., and function) on the vote class whose domain is vote and whose range is vote response. The values of the the function when applied to vote individual s will the the individuals 'yes' and 'no'.  You will especially find this less disruptive to your model when you want to add other individuals to the vote response type, such as 'abstain'.   This way also, other predicates on vote, such as who is the voter, etc. etc.,

here is a query that lists all the vote responses

SELECT * WHERE { ?vote a vote:Vote ; vote:hasResponse ?response }
[vote] response
vote:MyVote vote:Yes
vote:YourVote vote:No

 
- 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
 



--
William Frank

413/376-8167


This email is confidential and proprietary, intended for its addressees only.
It may not be distributed to non-addressees, nor its contents divulged,
without the permission of the sender.

_________________________________________________________________
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)

<Prev in Thread] Current Thread [Next in Thread>