- From: Danny Ayers <danny@panlanka.net>
- Date: Sun, 29 Apr 2001 22:49:22 +0600
- To: <www-rdf-interest@w3.org>
I'm pretty sure there needn't be a contradiction, caused by if...then...else, it's just how you actually express it - I'll try and find the exact bit, but I think it's done in DAML+OIL using : something is a subclass of NOT something else --- Danny Ayers http://www.isacat.net <- -----Original Message----- <- From: Seth Russell [mailto:seth@robustai.net] <- Sent: 29 April 2001 22:14 <- To: Murray Altheim; Danny Ayers <- Cc: info@jan-winkler.de; www-rdf-interest@w3.org <- Subject: Re: "If" and "else" in RDF <- <- <- From: "Murray Altheim" <altheim@eng.sun.com> <- <- > You have guys have me really confused. Are you trying to find a way to <- > express a material implication relationship, or perform a programmatic <- > function? Turn RDF into a programming language? I don't get <- it. Expressing <- > relationships is one thing, actually acting on them is a whole <- different <- > bahoosus. <- <- Thanks, I think you have put you finger on the confusion. <- Perhaps it was my <- silly post which first started conflating the declarative description of <- potential states of affairs with the actual acting on these <- representations <- by an agent to determine the actual state of affairs. <- <- From: "Danny Ayers" <danny@panlanka.net> <- <- > I think the confusion stems from the fact that 'if' and 'then' <- (/'else') <- are <- > commonly used in both declarative and imperative computer languages. In <- the <- > declarative context if...then... goes right back to the basic <- connectives <- of <- > propositional logic, where one can say if <something> then <something <- > else> - a relationship is stated, there is no processing <- involved. RDF is <- a <- > declarative language (a representation language, whether or <- not you call <- it <- > a programming language is probably irrelevant), so surely this is the <- > appropriate context here. <- <- I agree that the confusion is based on the fact that RDF is a declarative <- language, whereas "if_then_action" is a programming language expressing <- potential changes to states of affairs. I believe the problem <- stems from <- the idea that a declarative language should always tell the <- truth. For the <- RDF data model that amounts to saying that every labeled directed arc you <- draw, must be deemed true in the model. You are not supposed to state a <- contradiction; but that is exactly what you need to do to declare a <- "if_then_action". <- <- So getting back to Jan's question (and his most recent example <- from an off <- line discussion): <- <- From: "Jan Winkler" <jan_wi@jan-winkler.de> <- <- > if (mything:tax > '100$') then(mything:tax-type = 'not cheap') <- > else (mything:tax-type = 'cheap') <- > How should I do it without "if-then-else"? (to express a result or an <- > inference) <- <- The problem is that to accurately represent that in a labeled <- directed RDF <- graph, you must end up with a statement that might look something like <- this: <- <- :Mything:tax rdfs:label 'cheap' , 'not cheap'. <- <- which is plainly a contradiction. In other words you are required to <- declare potential facts which are in disjoint contexts .... and <- the formal <- logicians out there might object. <- <- I think this actually can be done with no contradiction ... but <- we will need <- to introduce some new concepts. I have taken a stab at it in <- the graph at <- [1]. <- <- [1] http://robustai.net/mentography/disjointDecision.gif <- <- Note that nodes that are black on white represent the things in <- our domain <- of discourse and static relationships between them. The context nodes <- (black on orange) allow us to state your "if-then-else" <- restraint in a way <- that is not contradictory. However it is not meaningful unless <- some active <- process (black on red) actually computes the state of actual <- affairs (black <- on blue). <- <- Hopefully my silly detailed view of things does not add too much to the <- confusion .... <- <- Seth <- <-
Received on Sunday, 29 April 2001 12:53:24 UTC