Re: rdf as a base for other languages

Jonathan Borden (J), Wolfram Conen (W) wrote:
J: Hence what should be a simple construct:
J:  (not (color sky blue))
J: becomes contorted.

W: Yes, if you model this as (for example):
W: [sky color blue]
W: [r type statement][r subject sky][r predicate color][r object blue]
W: [r hasTruthvalue not]
W: it becomes a little bit diffult* (see additional remark below, if you
W: like).
 
J: Not just "difficult", I would say this is a logical contradiction.

Before we could talk about contradictions, we would have to agree on
semantics (of RDF/set of triples). It is not a contradiction "per se".
Here is a way to give it some possible meaning with a mapping into a
suitable host formalism.

Map each triple [s,p,o] into an instance of a predicate triple(s,p,o).
Add the rules:
reifies(R,S,P,O) <= triple(R,type,statement) /\ 
	triple(R,subject,S) /\ triple(R,predicate,P) /\ triple(R,object,O).
falsified_resource(R) <= statement_known_as_true(R,hasTruthValue,FALSE).
statement_known_as_false(S,P,O) <= triple(S,P,O) /\ reifies(R,S,P,O) /\ 
	falsified_resource(R).
statement_known_as_true(S,P,O) <= triple(S,P,O) /\
	not(statement_known_as_false(S,P,O)).
[Technical note: read as Datalog, Prolog would require tabbling].
Now, you could use the statement_... predicates for your further
inferences (for example in your axiomatization of RDF Schema in the host
formalism.)

You may not consider this to be a perfect way of giving some meaning to
(a part of) RDF, but it seems not to be completely unreasonable (I hope)
- and the triples are not a contradiction any more. (this is to say that
before we have agreed on semantic interpretation, we probably shouldn't
say that a set of triples is contradictory).

J: Removing the [sky color blue] triple makes it merely contorted
J: (i.e. 5 triples for 2 statements) and suppose we then apply "not" to
the
J: entire expression, we cannot reconstitute the supposed 'fact' [sky
color
J: blue] without 'unreifying' the group of 4 statements. 

Once you start to "interpret" triples with a host formalism, you may
easily get rid of reification if you interpret it as nesting. That is:
the 2nd version from above can be written as [[sky color blue]
hasTruthValue FALSE]. (for the first, you would also add [sky color
blue]). You "only" have to write useful mappings and axioms to deal with
this nesting.

J: The usual rules of a
J: not applied to a not would be to simply remove 
J: the not e.g. (not (not s)) =>
J: s, but (not (not s)) where s is a reified statement implied the
reified
J: statement - no? 

Do you mean that you can not encode this without asserting not(s) with
the suggested method (you can, as long as you do not make the first [r
hasTruthValue FALSE] explicit - that is: keep on reifying ... ;)?

In the rules given above, the reduction from not(not(s)) to s is already
contained (recursion helps, at least sometimes ;)(the rule set would
have to be adapted to give a version for the second alternative with the
left-out triple).

J: regardless this seems contorted at best.

Yes, sure, but all we have are triples and so we have to make something
useful out of it - and can't this be done, for exmaple, with "formal"
mappings of RDF triples into constructs of a host formalism? wouldn't it
be nice if some such mappings would be availaible (usable like a
toolbox) and each one could pick out what he needs, make this explicit
and start to interoperate happily?  (Like a "Little languages" approach
with explicit semantics - simple approach: give basic transformations
and define the rules for predicates with Literals as objects of a
"DefinedAs" property, perhaps for multiple host formalisms (xml:lang
;)). Do we really require one semantic or a sequence of language layers?
Why not provide means to (explicitly) express the semantics of
constructs from within RDF and some very basic mappings and let each one
express precisely what he wants to express: "I use mapping A to host
formalism B and here are my predicate definitions" (all given in an RDF
document). Well, ok, enough for now. Anyway: Thanks, Jonathan to give
reason to think about that stuff again. 
 
Best,
	Wolfram

Received on Monday, 4 June 2001 20:18:29 UTC