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: Change Request toward B4 (was Re: [xdi] XDI Grapher)


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.



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