OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Update to XDI RDF metagraph model and answers to Bill


First, I just posted another update to the proposed XDI RDF graph model spec at:

 

            http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel

 

This contains a very important proposed modification to the metagraph model arising out of the discussion in which Bill most recently posted a message at:

 

            http://lists.oasis-open.org/archives/xdi/200901/msg00028.html

 

I’m sending this message to a new thread on the metagraph model that addresses Bill’s final question in that message:

 

> Right now $has seems to be used in different ways depending on who you talk to and

> I'd like to see us determine and document exactly how it's used.

 

Just like the discussions Nick Nicholas and I had over the holidays, Bill’s questions forced me even deeper into the metagraph semantics. The idea from the start has been for the semantics of the metagraph to be rooted in the logic of directed graphs, not in human language semantics, because we MUST have the machine-readablility of the former, while we would LIKE to have the human-readablility of the latter. So we need to map from logic ==> human semantics and not vice versa.

 

This helped result in five conclusions based on these discussions and the reading/research I did over the holidays.

 

#1 All the metagraph predicates are rooted in the concept of binary relationships (http://en.wikipedia.org/wiki/Binary_relations).

 

#2: The semantics of $a fundamentally express _type relations_ as rooted in type theory (http://en.wikipedia.org/wiki/Type_theory).

 

#3: The semantics of $has fundamentally express _order relations_ as rooted in order theory (http://en.wikipedia.org/wiki/Order_theory).

 

#4: The semantics of $is fundamentally express the concept of equivalence relations (http://en.wikipedia.org/wiki/Equivalence_relation).

 

#5: Based on this, the semantics best suited to express the inverse directionality of an XDI predicate is $is, not $a !

 

As surprising as this last conclusion was, it instantly solved the issue that had been nagging at me for as long as we’ve been saying that the inverse of $is$a is really $a$is$a and that the latter “contracts” or “simplifies” to $a. Based on the strict semantics of $has expressing ordered set relationships (more below), $a$is$a does NOT “contract” or “simplify” to $a.

 

By changing the metagraph predicate that expresses the inverse of another predicate to $is, we solve that problem – now the inverse of $a is $is$a, the inverse of $has is $is$has, and the inverse of $has$a is $is$has$a. Very clean, very logical, and reads (in English) very similarly to the way we have using $a for inverse relationships – see the updated examples on http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel. I know this is an important and core change to the metagraph model, but it is one that solves a number of key issues, so please speak up if you have any problems with it.

 

***********

Now, about $has. To answer Bill’s question (and I think also Giovanni’s earlier question that helped start the original thread), by this tightened definition, $has is strictly a way to express that a set of XRIs form an ordered set (http://en.wikipedia.org/wiki/Ordered_set). That ordered set is a new resource (node in the graph) distinct from any subset that is a member of the ordered set.

 

So, as we say in the example of the $has section of http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel, as an XDI address, the XRI +a+b+c+d infers all of the following XDI statements:

 

        +a/$has/+b             ==>     +a+b
        +b/$has/+c             ==>     +b+c
        +c/$has/+d             ==>     +c+d
        +a/$has/+b+c           ==>     +a+b+c
        +a+b/$has/+c           ==>     +a+b+c
        +a/$has/+b+c+d         ==>     +a+b+c+d
        +a+b/$has/+c+d         ==>     +a+b+c+d
        +a+b+c/$has/+d         ==>     +a+b+c+d

 

$has it does not infer anything else besides this. For example,

 

1) It does not infer set membership, i.e., +a+b+c does not infer that +c is a member of +a. It doesn’t infer anything about the relationship of +a and +c other than +a and +b form an ordered set and +b and + c form an ordered set, so +a and +b and +c form an ordered set.

 

2) It does not infer type or class relationships, i.e., +a+b+c does not infer that +b is a +a, or that +c is a +b.

 

***********

Hope this helps. I’ll respond separately to some of Bill’s and Markus’ and Giovanni’s other questions – this is just what happens when you finally dive down into the real specs.

 

=Drummond

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]