[Zope3-dev] Re: Zope3-dev Digest, Vol 25, Issue 37

[Jean-Marc Orliaguet]

Michel Pelletier wrote:

>>From: Olivier Grisel <ogrisel at nuxeo.com>
>>Subject: [Zope3-dev] Re: [DRAFT] local portlets and perspectives
>>    
>>
>
>  
>
>>>(SellerURI, merchandiseURI, BuyerURI, "Sale Transaction")
>>>
>>>      
>>>
>>Let's rewrite this relation to a prolog equivalent fact:
>>transaction(SellerURI, merchandiseURI, BuyerURI, "Sale Transaction").
>>
>>There is no primary key in that relation. We could add one such as 
>>TransactionURI for instance :
>>
>>transaction(TransactionURI, SellerURI, merchandiseURI, BuyerURI, "Sale 
>>Transaction").
>>
>>In this case we could rewrite this fact without loss of information 
>>using only binary relations/predicates by projecting it:
>>
>>transactionSeller(transactionURI, SellerURI), 
>>transactionMerchandise(transactionURI, merchandiseURI), 
>>transactionBuyer(transactionURI, buyerURI), 
>>transactionType(transactionURI, "Sale Transaction").
>>
>>This description is then equivalent and RDF friendly. However it 
>>requires the introduction of a primary key which was implicit in the 
>>first description and is much more verbose.
>>    
>>
>
>I think the original triadic statement can be encoded with one rdf
>triple + context in rdflib:
>
>Graph.add((SellerURI, merchandiseURI, BuyerURI), TransactionURI)
>
>Where TransactionURI is the context.  I'm still feeling that these two
>models are either equivalent, or there is some property of triadic
>relations that I just don't "get" yet.  This paper:
>http://www.cs.indiana.edu/pub/techreports/TR606.pdf also appears (from
>reading the first five pages) to state that reified RDF triples *are*
>Peirce relations, which seems to make sense as they are statements about
>statements, although I can't claim to really understand the guts of the
>paper.
>
>I want to reiterate to you guys that I'm not trying to be argumentative
>or prove that one thing is better than the other, I take a deep interest
>in these subjects and I want to know as much as possible about them.
>But unfortunately I think we've strayed off the topic for this list.
>
>-Michel
>
>  
>

Hi Michel,

the whole issue with RDF I think is: many who build representational
models have noticed that the (subject, object, predicate) triad is not
sufficiently flexible to represent knowledge that has to do with laws,
agreements, abstract concept, regularity, phenomena that evolve with
time, etc. All these phenomena cannot be represented by using a long
chain of dyadic predicates. By adding new dyadic relations into the
graph you are not adding more information into the model,  you are just
adding more data.

Every language on Earth uses verbs that correspond to monadic, dyadic or
triadic predicates. No verb in any language uses predicates with four
terms. It means that with 3 kinds of predicates you can express just any
idea, but that you cannot with dyadic predicates only express all ideas.

For some reason, RDF was designed on the basis of dyadic predicates
(subject, object). It also means that there is a whole category of
phenomena that cannot be represented in RDF-based models, and that you
will have to use a language such as Python on top the model to add the
missing relations. You can use adapters, for instance; these are great
triadic relations.   

The only valid solution would be to break the RDF model and introduces
quads, but this would also mean breaking existing software and lose
interoperability with the triple model.

No one is willing to do this, so instead you'll find such fixes as:

- reification (turning an abstract concept into a concrete thing), i.e.
since a triadic idea cannot be modelled using a combination of dyads, we
will give it a name, and then we will be able to say: "there is a
transaction", "the transation has a buyer", "the transaction has a
seller", etc.

- adding a "context", i.e a fourth element, and use it to refer to the
relation:

  graph.add(triple, context)

  which is a variation on the reification method, but maybe easier to use.

All of this is meant to fix a model on an API level without breaking it,
but it is still dyadic relations that are used to refer to other dyadic
relations ... Basically: if you add the thing that is missing, you break
the model..

best
/JM