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 -->




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

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




                        (=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





implies the XDI subect




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:





implies the XDI subject




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):







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:



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

logically equivalent to the three statements:





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






implies the XDI subject




but it does not imply the XDI subject




because, as we saw above, the XDI statement =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





The result is the XDI subject




But these two $has statements CANNOT be expressed as




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




which can also be expressed as






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):











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:


















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.



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