Re: [xdi] Change Request toward B4 (was Re: [xdi] XDI Grapher)

1) You say, “[the fact that] +b+c and (+b+c) are NOT equivalent, in my opinion this is not a problem for XDI, as long as they could be resolved to the same CONCEPT”.

They do not resolve to the same concept. There is no way semantically that we can assert that any XRI and the reification of that same XRI resolve to the same concept. To use an analogy, this would be like saying that a number and the absolute value of that number are always the same number. For example, +3 and |+3| represent the same number, but -3 and |-3| DO NOT represent the same number. (Again, this is just an analogy, I’m not saying reification and absolute numbers are the same thing.)

My point is, from a pure XDI standpoint, +a and (+a) are two different XRIs representing two different nodes in the XDI graph. The only statement I believe we can say is that (+a) identifies the XDI context containing the XDI subject +a. But that is NOT the same as saying (+a) and +a are either: a) equivalent, or b) represent the same concept.

2) You say that full associativity, as opposed to left or right associativity, conflicts with the $is$a semantics of the $has operator. I believe the exact opposite is true, i.e., ONLY full associativity is consistent with the $is$a semantics of the $has operator.

Let’s first illustrate this with +a+b+c, and then with “Markus parking slot”.

+a+b+c/$is$a/+b+c

These are both logically consistent. Let’s now apply them to “Markus parking slot”:

3) Thirdly – and this may be the ultimate source of the confusion – you say that, for

Markus parking slot

“you are creating an outgoing arc from the node ‘Markus parking’, which is ‘slot’.”

In fact, $has statements, when translated to RDF statements, DO NOT CREATE OUTGOING ARCS. They only create new XDI subject nodes. Only a $has$a statement creates an outgoing arc.

This also answers Bill’s question about why the parentheses (reification) around the middle of the two transforms for a $has statement:

The parentheses create the reification of +a/+b into a new XDI subject – a single node. So once again, when translated to an RDF graph, an XDI $has statement does NOT produce an outgoing arc. It only produces a new XDI subject. That’s why $has statements cannot have cardinality.

The XDI statement that produces an outgoing arc in an RDF graph is a $has$a statement.

On Thu, Jan 7, 2010 at 5:08 AM, Giovanni Bartolomeo <giovanni.bartolomeo@uniroma2.it> wrote:

Hello Drummond,

I think we are very close to the core of the matter.

Actually there are examples where you can split terms on the left or right side and ones which do not allow this.
House door keyhole and almost all the ones you quoted right now belong to the first case; whereas Markus parking slot and contract Markus' signature to the second one.

The reason why $has cannot be associative in the meaning you pointed out, but only LEFT ASSOCIATIVE, resides in one important implication we have in the semantics of the $has operator:

+a/$has/+b implies +a+b/$is$a/+b

this creates a dissimetry between the right and the left operands, which reflects in the semantic (RDF) model underlying the whole XDI specs. In fact, if you take

Markus parking slot

you are assigning a property, (attribute, member,... whatever you want to call it), to Markus. The outgoing arc from markus is parking slot, which is an instance of slot.

But if you split this differently

Markus parking slot

you are saying something different, twice: first you are creating an outgoing arc from the node Markus parking, which is slot. This is not correct as do not reflect what we wanted to say (not only Markus parking but every parking has slots). Second, Markus parking itself is an RDF expression which keep Markus as node and parking as an outgoing arc. Therefore you are asserting a second fact, that Markus has a property called PARKING, whereas the original statement said only that Markus has a PARKING SLOT!

Syntactically, the only way I know to tell a parser that +parking+slot, a kind of +slot, is a property of =Markus is to forbid that +parking can be attached to =Markus, and force to attach it to +slot. In matemathics this happens using parenthesis, but, if my understanding is correct, also XRI parsers work the same way, i.e. resolving first what is inside the cross reference and then the rest.

Finally coming to your point about syntax: even if, SYNTACTICALLY, "+b+c and (+b+c) are NOT equivalent", in my opinion this is not a problem for XDI, as long as they could be resolved to the same CONCEPT. Please note that also in mathematics we can use different syntaxes to resolve to the same result: +7 = (+7) = ((+7)) = (((+7))),... it is not the syntax, but the semantics which cares.

Kind Regards,
Giovanni

Def. Quota "Drummond Reed" <drummond.reed@xdi.org>:

Giovanni,

Thank you for writing such a clear message about what you perceive the
problem is. This same issue became clear to me when working on the box
graphing (which I propose to rename to “cell graphing” because it’s a better
metaphor for dealing with data relationships).

Unfortunately I believe that defining $has relations to be strictly left
associative actually introduces a logical inconsistency for which I know of
no solution, and which would be fatal to our goal of making sure XDI is
logically consistent. However, the alternative of defining $has relations as
neither left nor right associative, but just associative (per the definition
from Wikipedia below) avoids this logical inconsistency, thereby solving
this problem and keeping XDI semantics consistent.

Let me first provide the definition of associativity from Wikipedia, then
explain my reasoning in more detail.

***** FROM http://en.wikipedia.org/wiki/Associative *******

Formally, a binary operation [image: *\!\!\!]on a
set<http://en.wikipedia.org/wiki/Set_%28mathematics%29>
*S* is called *associative* if it satisfies the *associative law*:

[image: (x * y) * z=x * (y * z)\qquad\mbox{for all }x,y,z\in S.]

*Using * to denote a binary
operation<http://en.wikipedia.org/wiki/Binary_operation>performed on a

set
*

[image: (xy)z=x(yz) = xyz \qquad\mbox{for all }x,y,z\in S.]

*An example of multiplicative associativity*

The evaluation order does not affect the value of such expressions, and it
can be shown that the same holds for expressions containing *any*
number of [image:
*\!\!\!]operations. Thus, when [image: *\!\!\!]is associative, the
evaluation order can therefore be left unspecified without causing
ambiguity, by omitting the parentheses and writing simply:

*xyz*,

However, it is important to remember that changing the order of operations
does not involve or permit moving the operands around within the expression;
the sequence of operands is always unchanged.

A very different perspective is obtained by rephrasing associativity using
functional notation: *f*(*f*(*x*,*y*),*z*) = *f*(*x*,*f*(*y*,*z*)): when
expressed in this form, associativity becomes less obvious.

Associativity can be generalized to n-ary
operations<http://en.wikipedia.org/wiki/Arity>.

Ternary associativity is (abc)de = a(bcd)e = ab(cde), i.e. the string abcde
with any three adjacent elements bracketed. N-ary associativity is a string
of length n+(n-1) with any n adjacent elements
bracketed[1]<http://en.wikipedia.org/wiki/Associative#cite_note-0>

.

******** END WIKIPEDIA EXCERPT ********

What I am proposing is that the definition of $has relations in the spec
(i.e., the definition currently at
http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel#A.24hasand.24is.24has)
should be clarified to be just associative as defined above, and NOT either
left associative or right associative. The rest of this message explains
why.

First, let me explain the logical inconsistency that either left or right
associativity introduces. I’ll start by saying that I believe the source of
misunderstanding in this area is the XDI use of parentheses (XRI
cross-references). The problem is that in mathematics, parenthese are only
used to group mathematical operations. Other than precedence, *they have no
other meaning*.

In both XRI and XDI, however, parentheses are 100% significant. They are *part
of the identifier*. Only in XDI do we define equivalence rules between XDI
addresses that specify that certain XDI addresses that include parentheses
are equivalent to others that do not. In fact these rules apply ONLY to $has
statements, and they follow these very strict equivalence rules:

+a/$has/+b <==> (+a/+b) <==> +a+b

Again, it’s very important to clarify that the parentheses in the center XDI
statement above are NOT OPTIONAL. They are required or else the equivalence
is broken. In other words, +a/$has/+b is NOT equivalent to +a/+b and +a/+b
is NOT equivalent to +a+b.

So, let’s now turn to your example:

******* EXCERPT FROM GIOVANNI’S MESSAGE ********

I think the only reason of considering +a/$has/+b+c and +a+b/$has/+c as
producing the same statement +a+b+c was that it was not very clear how the
$has operator work. But after our last phc we agreed that $has is a LEFT
associative operator. This is enough to tell a parser that when a
+a+b/$has/+c is encountered, the a+b+c statement is produced. Whereas when
it finds +a/$has/+b+c, then the +a(+b+c) statement must be produced.

******* END EXCERPT ******

Here’s why it is impossible for +a/$has/+b+c to produce (i.e., be equivalent
to) +a(+b+c). Following our own rules for $has statements, +a(+b+c) expands
(is equivalent to):

+a/$has/(+b+c) <==> (+a/(+b+c)) <==> +a(+b+c)

If that is true, and you are saying at the same time that…

+a/$has/+b+c <==> (+a/(+b+c)) <==> +a(+b+c)

…then it would follow that…

+a/$has/+b+c <==> +a/$has/(+b+c)

…which, as I explained above, is a complete contradiction, since +b+c and
(+b+c) are NOT equivalent.

This is why example B4 in the box graphing examples that you refer to
asserts that all of the following XDI statements are equivalent:

(+a/+b)/$has/+c

+a+b/$has/+c
((+a/+b)/+c)
(+a+b/+c)
+a/$has/(+b/+c)

+a/$has/+b+c
(+a/(+b/+c))
(+a/+b+c)
+a+b+c

The reason they are all equivalent is that if you apply these two simple
transformation rules…

1) All XDI statements *[x1]/$has/[x2]* TRANSFORM TO *([x1]/[x2])*

2) All XDI statements (*[x1]/[x2])* TRANSFORM TO *[x1][x2]*

…to all nine XDI statements above, then all nine reduce to:

+a+b+c

To me, this is logically consistent with full associativity. For example, in
the following sequence of numbers related by addition….

7 + 8 + 3 + 4

….you get the same result no matter where you place parentheses, or how many
parentheses you add. That’s because the addition operation is not left
associative, or right associative, but fully associative.

I also believe it is graphically consistent. By this I mean that if you
picture each $has relation as creating a directed path…

+a -----> +b -----> +c -----> +d

…then, just like the addition operation above, any way you group the
segments of this path while maintaining the same overall order, once you put
these groups back together, you end out with the same overall path.

Now, with all that said, let me finally turn to your point about English
language analogies. You suggest that the statement “Markus parking slot”
only follows from asserting “Markus parking has a slot” and NOT from “Markus
has a parking slot”.

In English, I would assert that phrase resulting from a logical sequence of
three or more nouns, where each noun describes the next, is full
associative, meaning that like the set of numbers being added above, it can
be grouped in any set of sequences, each of which makes its own logical
unit, that when fully combined in the same sequence, creates the same final
logical unit.

So, to be clear, I am not asserting that the individual logical unit
groupings are identical, only the final result is identical. Here are three
examples:

Markus ball cover

Markus ball cover

Markus ball cover

car engine fan blade

car engine fan blade

car engine fan blade

car engine fan blade

Asia continent jetstream
direction indicator

Asia continent jetstream direction
indicator

Asia continent jetstream direction indicator

Asia continent jetstream direction indicator

Asia continent jetstream direction indicator

I would assert that the relationship between two nouns in the English
language – without any special punctuation – is the same as the $has
relation in XDI. And that the addition of quotes grouping two or more of the
above words is roughly the equivalent of what parentheses do in XDI. For
example…

Asia “continent jetstream” direction indicator

…can only be parsed into:

Asia “continent
jetstream” direction indicator

Asia “continent jetstream” direction
indicator

Asia “continent jetstream” direction indicator

Asia “continent jetstream” direction indicator

This illustrates that in English, as in XDI, the addition of quotes to the
sequence of words changes the semantics, i.e., the same sequence of English
words with and without the quotes are NOT equivalent.

I hope this helps. It is such an important point that we’ll make it the
first agenda item in tomorrow’s telecon (I’m sending the agenda next).

=Drummond

******* BELOW IS GIOVANNI’S ORIGINAL MESSAGE ********

On Wed, Jan 6, 2010 at 12:50 AM, Giovanni Bartolomeo <
giovanni.bartolomeo@uniroma2.it> wrote:

Dear Drummond, Markus,

I want to come back on point B4.

I think the answer is whether or not the XRI can be simplified by
contracting $has statements.

In B4, all of the following statements simplify to the same maximally
contracted XRI: +a+b+c .

(+a/+b)/$has/+c
((+a/+b)/+c)
(+a+b/+c)
+a/$has/(+b/+c)
(+a/(+b/+c))
(+a/+b+c)
+a+b+c

To me, this is a risk because it creates inconsistency in the semantic
model.
As you know, I've highlighted this in a previous email:

Consider now: contract markus' signature

1) contract Markus has signature: you are asserting that a "specific"
MARKUS (contract Markus) has a signature
2) contract has Markus' signature: you are asserting that CONTRACT has a
specific SIGNATURE (Markus' signature)

only 2) seems to make sense to me.

Drummond answered that:

Now, in this case, you added particulr punctuation used in the English
language: the possessive apostrophe. The use of that punctuation creates a
conjunction between "markus" and "signature" that cannot be broker apart.
This has a direct analog in XDI RDF - using a cross-reference to bind the
two XRIs into one. In other words, instead of saying +a+b+c which is three
XRI subsegments, you are saying +a(+b+c) which is two XRI subsegments.

I was not sure of this, as in other cases, when the possessive statement
appears as subject-predicate, like "Drummond's friend", we do not use at all
cross references and we simply express this using the $has statement:
=drummond+friend

But, the very argument is that this may happen also in other kind of
statements, not necessarily involving the possessive apostrophe.

Condider the following example where:

+a is =Markus
+b is +parking
+c is +slot

1. (+a/(+b/+c)) (=Markus/(+parking/+slot)) (=Markus/+parking+slot)
=Markus/$has/+parking+slot, +parking/$has/+slot

2. ((+a/+b)/+c) ((=Markus/+parking)/+slot) (=Markus+parking/+slot)
=Markus/$has/+parking, =Markus+parking/$has/+slot

Despite they look similar, they are asserting DIFFERENT concepts.
Bullet 1. says that markus owns a parking slot. Furthermore it asserts that
a parking has a slot.
Bullet 2. says that markus owns a whole parking, not a parking slot.
Furthermore it is saying that Markus's parking (i.e. one specific parking)
has a slot.

I think the only reason of considering +a/$has/+b+c and +a+b/$has/+c as
producing the same statement +a+b+c was that it was not very clear how the
$has operator work. But after our last phc we agreed that $has is a LEFT
associative operator. This is enought to tell a parser that when a
+a+b/$has/+c is encountered, the a+b+c statement is produced. Whereas when
it finds +a/$has/+b+c, then the +a(+b+c) statement must be produced.

I propose an AP for a CR on example B4 and consequently on the definition of
$has given in:

http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel#A.24hasand.24is.24has

Kind Regards,
Giovanni

PS: Markus's visual tool is great! Congratulation, Markus! :-)

On Wed, Jan 6, 2010 at 12:50 AM, Giovanni Bartolomeo <
giovanni.bartolomeo@uniroma2.it> wrote:

Dear Drummond, Markus,

I want to come back on point B4.

I think the answer is whether or not the XRI can be simplified by

contracting $has statements.

In B4, all of the following statements simplify to the same maximally
contracted XRI: +a+b+c .

(+a/+b)/$has/+c
((+a/+b)/+c)
(+a+b/+c)
+a/$has/(+b/+c)
(+a/(+b/+c))
(+a/+b+c)
+a+b+c

To me, this is a risk because it creates inconsistency in the semantic
model.
As you know, I've highlighted this in a previous email:

Consider now: contract markus' signature

1) contract Markus has signature: you are asserting that a "specific"
MARKUS (contract Markus) has a signature
2) contract has Markus' signature: you are asserting that CONTRACT has a
specific SIGNATURE (Markus' signature)

only 2) seems to make sense to me.

Drummond answered that:

Now, in this case, you added particulr punctuation used in the English

language: the possessive apostrophe. The use of that punctuation creates a
conjunction between "markus" and "signature" that cannot be broker apart.
This has a direct analog in XDI RDF - using a cross-reference to bind the
two XRIs into one. In other words, instead of saying +a+b+c which is three
XRI subsegments, you are saying +a(+b+c) which is two XRI subsegments.

I was not sure of this, as in other cases, when the possessive statement
appears as subject-predicate, like "Drummond's friend", we do not use at all
cross references and we simply express this using the $has statement:
=drummond+friend

But, the very argument is that this may happen also in other kind of
statements, not necessarily involving the possessive apostrophe.

Condider the following example where:

+a is =Markus
+b is +parking
+c is +slot

1. (+a/(+b/+c)) (=Markus/(+parking/+slot)) (=Markus/+parking+slot)
=Markus/$has/+parking+slot, +parking/$has/+slot

2. ((+a/+b)/+c) ((=Markus/+parking)/+slot) (=Markus+parking/+slot)
=Markus/$has/+parking, =Markus+parking/$has/+slot

Despite they look similar, they are asserting DIFFERENT concepts.
Bullet 1. says that markus owns a parking slot. Furthermore it asserts that
a parking has a slot.
Bullet 2. says that markus owns a whole parking, not a parking slot.
Furthermore it is saying that Markus's parking (i.e. one specific parking)
has a slot.

I think the only reason of considering +a/$has/+b+c and +a+b/$has/+c as
producing the same statement +a+b+c was that it was not very clear how the
$has operator work. But after our last phc we agreed that $has is a LEFT
associative operator. This is enought to tell a parser that when a
+a+b/$has/+c is encountered, the a+b+c statement is produced. Whereas when
it finds +a/$has/+b+c, then the +a(+b+c) statement must be produced.

I propose an AP for a CR on example B4 and consequently on the definition
of $has given in:

http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel#A.24hasand.24is.24has

Kind Regards,
Giovanni

PS: Markus's visual tool is great! Congratulation, Markus! :-)

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

xdi message