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: Realizations about $has statements


Giovanni  et al,

 

The work I have been doing with Markus and others on XDI patterns for personal data stores (PDS) have led me to an interesting realization. In doing cross-references between an XDI subject representing a person (=example in the examples below) and another representing a “persona” of that person (=example$1 in the example below), the following pattern (shown in X3 Simple) appears frequently:

 

=example            <--root XDI subject for an individual's PDS -->

            $is$a

                        +person

            +email$1

                        person@example.com            <-- a literal as XDI object -->

=example$1            <-- first persona -->

            $is$a

                        +home+person

            +home+email

                        (=example/+email$1)            <-- cross-reference to the literal above -->

 

Although we have used this form of cross-reference for many months now, when I returned to it after all our discussions of the semantics of $has statements, I realized that

 

            (=example/+email$1)            <==>            =example+email$1

 

This was particularly interesting since (=example/+email$1) is clearly the XDI address of the XDI object literal "person@example.com", however =example+email$1 is an XDI subject.

 

My conclusion was the realization that the XDI statement

 

=example/

            +email$1

 

implies the XDI subect

 

=example+email$1

 

and vice versa - which is what I think Giovanni has been saying for some time now.

 

This pattern can be repeated to any depth. For example the XDI statement:

 

=example+email$1

            $v$1

 

implies the XDI subject

 

=example+email$1$v$1

 

and vice versa.

 

This was startling to me because it means the distinction I have been maintaining (and Giovanni has been objecting to) between $has and $has$a statements—saying that $has statements identify a new XDI subject but only $has$a statements identify an XDI predicate on an existing XDI subject—is not needed. Rather a $has statement implies both that an XDI subject has a particular predicate AND that this relationship can be described by a new XDI subject.

 

If there is agreement on the TC about this, it means we can eliminate two metagraph predicates ($has$a and $is$has$a) in our current wiki spec. Note however that $has$a statements may still be a good way to express cardinality on the number of instances of a particular predicate. For example, following would be a way to express that =example must have at least one and at most three instances of a +email predicate (each of which must be unique of course):

 

=example+email

            $has$a

                        $min$1

                        $max$3

 

This realization also means I can complete another action item, which is to provide my feedback on the issue I had with one slide in the presentation Giovanni posted to the XDI doc repository last month.

 

In this slide, Giovanni says:

 

Therefore, the second part of the statement

=drummond/+friend/=markus is described by:

            =drummond+friend/$has/=markus

            =markus/$is$a/=drummond+friend

That is: =drummond/+friend/=markus is

logically equivalent to the three statements:

            =drummond/$has/+friend

            =drummond+friend/$has/=markus

            =markus/$is$a/=drummond+friend

 

The error I see here is that the rule I describe above -- that each XDI  subject/predicate relationship can be expressed as a new XDI subject -- does not extend to XDI objects.

 

In other words, the XDI statement

 

=drummond

            +friend

                        =markus

 

implies the XDI subject

 

=drummond+friend

 

but it does not imply the XDI subject

 

=drummond+friend=markus

 

because, as we saw above, the XDI statement =drummond+friend=markus

implies

 

=drummond+friend

            =markus

 

Here's another example that shows this semantically. Say we want to talk about the engine fan of a car. This could be represented by the following XDI statements

 

+car/$has/+engine

+ear+engine/$has/+fan

 

The result is the XDI subject

 

+car+engine+fan

 

But these two $has statements CANNOT be expressed as

 

+car/+engine/+fan

 

because that would be saying, "The engine of a car is a fan".

 

Instead, if you want to express the nested $has relationships as a single XDI statement, you must say

 

(+car/$has/+engine)/$has/+fan

 

which can also be expressed as

 

(+car/+engine)/$has/+fan

+car+engine/+fan

+car+engine+fan

 

So my conclusions about $has semantics are:

 

1) $has statements may represent any chain of nested XDI subject/predicate relationships to any depth. By "nested", I mean the following (using the +car example from above):

 

+car

            +engine

+car+engine

            +fan

+car+engine+fan

            +bolt

+car+engine+fan+bolt

            ...

 

2) This nesting pattern cannot include an XDI object, because an XDI object terminates the nesting.

 

3) A $has statement implies all the following XDI statements:

 

+x/$has/+y

+x/+y

(+x/+y)

+x+y

+x+y/$is$a/+y

+y/$a/+x+y

 

Example:

 

+car/$has/+engine

+car/+engine

(+car/+engine)

+car+engine

+car+engine/$is$a/+engine

+engine/$a/+car+engine

 

Again, if there is agreement across the TC on these points, then I'd suggest the next step is to update the wiki spec to reflect this revision to $has semantics. Let's discuss on this Thursday's TC telecon.

 

=Drummond



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