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