[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xdi] Change Request toward B4 (was Re: [xdi] XDI Grapher)
Hello Drummond,
let me answer in a reverse order:
point 3): 'creates' is probably not the right word, but 'describes' is.
According to http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel
The $has metagraph predicate describes the relationship between a node
and an outgoing arc in the XDI RDF graph. The subject of a $has
statement is the XRI of the node from which the arc originates, and
the object is the XRI of the arc.
therefore, =Markus+parking/$has/+slot describes an outgoing arc +slot
from =Markus+parking. Furthermore, the subject =Markus+parking, is a
reification of =Markus/+parking, i.e. there is a node =Markus with an
outgoing arc +parking.
The model is then not correct. The correct model is described ONLY by
=Markus/$has/+parking+slot.
point 2): sorry but this argumentation cannot be used, as you're
starting supposing the correcness of what you want the associativity
of $has to work.
> In my message I explain how all the following XDI statements
therefore you get that conclusion.
point 1): You seems to suggest that parenthesis are used to create
reification. The only example of reification we discussed right now is
+a+b, which is considered equivalent to (+a/+b). The semantics of
parenthesis is used here as a reification to avoid confusion with
+a/+b. But, when dealing with only one subject, like +a, what's the
meaning of reification around the single subject? I
Anyway, talk with you in few minutes...
Kind Regards,
Giovanni
Def. Quota "Drummond Reed" <drummond.reed@xdi.org>:
> Giovanni,
>
>
>
> Several points:
>
>
>
> 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”.
>
>
>
> In my message I explain how all the following XDI statements…
>
>
>
> (+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)
>
>
>
> …are equivalent because they all reduce to the same XDI statement:
>
>
> +a+b+c
>
>
>
> So, picking out two of the statements above, we have:
>
>
>
> +a+b/$has/+c
> +a/$has/+b+c
>
>
>
> These infer two $is$a statements:
>
>
>
> +a+b+c/$is$a/+c
>
> +a+b+c/$is$a/+b+c
>
> These are both logically consistent. Let’s now apply them to “Markus parking
> slot”:
>
>
>
> Markus parking slot is a slot.
>
> Markus parking slot is a parking slot.
>
>
>
> Both statements are true and logically consistent.
>
>
>
> 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:
>
>
>
> +a/$has/+b <==> (+a/+b) <==> +a+b
>
>
>
> 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.
>
>
>
> +a/$has$a/+b <==> +a/+b
>
>
>
> (Note there are no parentheses around +a/+b.)
>
>
> We'll discuss all this further on today's call.
>
>
>
> =Drummond
>
>
> 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.
>>
>>
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]