Re: [xdi] Realizations about $has statements

On Thu, Mar 25, 2010 at 8:45 PM, Drummond Reed <drummond.reed@xdi.org> wrote:

On Thu, Mar 25, 2010 at 9:58 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
So the point is that in a PDS you want to do this, right?

=example

            $is$a
                        +person
            +email$1
                        “person@example.com”

=example$1

            $is$a
                        +home+person
            +home+email
                        =example+email$1

This reference (in green) COULD be what you have here, but if it was, then that would actually be a reference to =example+email$1 as a subject. That would be a different pattern. Here's what that pattern would look like:

=example
            $is$a
                        +person
            +email
                        =example+email$1
=example$1
            $is$a
                        +home+person
            +home+email
                        =example+email$1
=example+email$1
            $is$a
                        +email
                        +home+email
            $value
                        “person@example.com”

Do you like this pattern better? Or the pattern that keeps the literal data values under the primary XDI subject and references them from the personas?

Not really sure how well it would work in practice.. If there were more subsegments than just =example and +email$1, how would I know where to break them up into their "subject" and "predicate" parts in order to follow the reference and find the literal value? I.e. in the above example, how do I know I have to look for subject =example and then for predicate +email$1, rather than for subject =example+email and then for predicate $1 ?

Exactly - that's the issue. It seems to me that there are two answers:

1) Extreme #1: put all literals that describe a primary subject under the primary subject, and have every persona reference them.

2) Extreme #2: give all literals their own XDI subject and have all personas reference them.

Again, which approach do you think will work better in practice?

=Drummond

On Mon, Mar 22, 2010 at 9:47 AM, Drummond Reed <drummond.reed@xdi.org> wrote:

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

xdi message