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: Re: golden triangle (was Re: [xdi] $is is the universal inverserestriction)


Dear Drummond,

Thank you for your answer! I agree to proceed this way, I'll edit the  
wiki page and once done I'll notify the ML in order to discuss  
proposed changes.

For convenience's sake, I report hereafter a summary of the issues  
discussed in this thread together with my comments, so that we could  
then resume the discussion from this list once I'll edit that page:

1) $has and $has$a have different meanings as agreed in last April

2) the golden triangle attempts to explain metagraph predicates [$is,  
$a, $has, $is$a, $is$has, $has$a] based on an intuition of their  
semantics. This could be helpful, but, I think, it is somehow  
different from a formal definition fitting a normative section. In  
addition I think that it does not fit some use cases; in particular

2.1) in the golden triangle, $is$a is a label for an arrow drawn from  
OBJECT to PREDICATE and I do not understand how this could be used to  
describe instantiation (e.g. the relationship between =drummond and  
+person)

2.2) in the golden triangle, $has$a represents (quoted from specs):

"traversal of two legs of the golden triangle: the $has leg expressing  
that a SUBJECT has a PREDICATE, and the $a leg expressing that a  
PREDICATE describes an OBJECT."

I do not understand how this could be used to describe composite  
subjects (e.g. the set =drummond+friend which is meta-described by  
=drummond/$has$a/+friend)

3) if we accept, BY DEFINITION, $is as metagraph predicate to express  
"inverse predication": we must be consistent with semantics associated  
to $is+x which is meta-described by $is/$has$a/+x and should read as:  
"the SET whose members fulfill $is/+x".

4) +x/+y/+x+y and +x/+y/+y: to the best of my efforts I cannot find  
any valid semantics for these statements.
__________________________

I'll probably miss some of next calls due to summer break, but will  
keep updated through emails.

I wish you and your family a wonderful and relaxing holiday!!

Kind Regards,
Giovanni





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

> Giovanni, I apologize for taking so long to respond -- as you know I am on
> vacation in Hawaii for my wife's birthday now, and getting ready for it
> really had me consumed last week. But I am here now and finally had some
> time to respond to the important points you make in your email. See my
> responses inline below.
>
> On Fri, Jul 2, 2010 at 8:39 AM, Giovanni Bartolomeo <
> giovanni.bartolomeo@uniroma2.it> wrote:
>
>> Dear Drummond,
>>
>> for the sake of clearness the page I'm referring is:
>> http://wiki.oasis-open.org/xdi/XdiOne/AddressingAndGraphModel
>>
>> please see my answers inline... looking forward for your comments.
>>
>> Kind Regards,
>> Giovanni
>>
>>
>> Def. Quota "Drummond Reed" <drummond.reed@xdi.org>:
>>
>>  Giovanni,
>>>
>>> The golden triangle has been working very well -- at least for me -- as a
>>> vehicle for explaining the simplicity at the heart of the XDI metagraph
>>> predicates/verbs.
>>>
>>> See inline for more responses.
>>>
>>> On Thu, Jul 1, 2010 at 8:10 AM, Giovanni Bartolomeo <
>>> giovanni.bartolomeo@uniroma2.it> wrote:
>>>
>>>  -1. I'd like "predicate" better, to maintain backward compatibility with
>>>> RDF.
>>>>
>>>
> Yes, I too prefer to stick with predicate, because of the compatability with
> RDF -- even if XDI does allow partial statements.
>
>
>>
>>>> BTW there are currently many issues with the "golden triangle" which are
>>>> still very obscure (at least to me), including: $is$a as $word relating
>>>> predicates with objects,
>>>>
>>>
>>>
>>> The golden triangle only explains the origins and semantics of the
>>> metagraph
>>> predicates. It doesnt' literally say that $is$a related a predicate to an
>>> object.
>>>
>>
>> In the specs we have this sentence "$is$a, describes the relationship
>> between an object and a predicate". If this should be not litterally
>> understood, how should be understood otherwise?
>
>
> I agree with you that that sentence is not very helpful -- in fact the
> description of how to interpret the golden triangle should be written much
> better in the spec. I would be happy to take that action item. However see
> the rest of my comments about the golden triangle below.
>
>
>>
>>
>>  For example, in the XDI statement
>>>
>>> =drummond
>>>  $is$a
>>>    +person
>>>
>>> all the standard XDI model applies, i.e., =drummond is the subject, $is$a
>>> is
>>> the predicate (or "verb" as Joseph suggests), and +person is the object.
>>>
>>> The semantics of the $is$a statement simply say that +person is an arc
>>> that
>>> points at the subject =drummond. That's what it means to assert that a
>>> resource is of a certain type.
>>>
>>>
>> Humm.. but how do you read this in the golden triangle?
>>
>
> How I "read" it in the golden triangle is that $is$a statements represent an
> assertion that the XDI graph node =drummond has an incoming arc +person, and
> thus the semantics are that the resource =drummond is of the type +person.
> IMHO, that is the extent to which the golden triangle can help provide the
> semantics of the metagraph predicates.
>
> By contrast, how do you propose to define the semantics of $is$a statements?
>
>
>>
>>
>>
>>>  $is and self referencing arc definition,
>>>>
>>>
>>>
>>> Please do explain what the issue here is. When I present XDI, this is the
>>> first example I use to explain why identifiers in XDI are non-opaque, and
>>> it
>>> usually fires off "the big light bulb" in the audience. Suddenly they
>>> start
>>> to understand the power of XDI - that you can algorithmically state the
>>> inverse of any XDI predicate just by restricting it with $is.
>>>
>>>
>>>
>> Current specs say:
>>
>> "Because it is self-referential, $is plays a special role in restricting
>> (prefixing) other XDI predicates: it expresses the inverse of the extension"
>>
>> So it is obscure to me how you come to this conclusion about inverse
>> predicates, from the fact that "$is is self referential"? I know that your
>> intuition behind is the verb "to be" in English, $is+something or
>> $be+something, but this is what you read in it, there is no formal proof
>> which can demonstrate that, e.g., $is+father is the same as +child. Of
>> course you can give it by definition, however, note that $is+x is two
>> subsegments, then is described by $is/$has$a/+x and - see also below -
>> should read as: "the SET whose members fulfill $is/+x".. so what does this
>> mean?
>
>
> Actually, my intuition was never based in the verb "to be" in English - from
> my point-of-view, that was just an interesting form of corroboration. My
> intuition was based in the physical properties of a reflexive arc in a graph
> -- that fact that such an arc is its own inverse, since it starts and ends
> at the same node.
>
> I agree with you that we should provide an explanation in terms of  theory
> as you discuss below.
>
>
>>
>>
>>  $has$a definition as traversal of subject and predicate, +x/+y/+y and
>>>> +x/+y/+x+y reintroduced, after we agreed that they were not needed,
>>>> etc...
>>>>
>>>>
>>> I don't understand. We spent several months figuring out the new
>>> definitions
>>> of $has and $has$a. That was the "big ahha" that triggered the change in
>>> the
>>> metagraph model, and thus the revision to the spec. Can you send a writeup
>>> of what you believe the issue is?
>>>
>>>
>>>
>> Sorry, but the point that we agreed was different (
>> http://lists.oasis-open.org/archives/xdi/201004/msg00031.html):
>>
>> "Drummond put it this way: +a/+b identifies the members of the set +a+b,
>> and +a+b identifies the set whose members fulfill +a/+b. Drummond concluded
>> that +a/+b and +a+b are linked in that way, but the reason they are not
>> "resolution equivalent" in the graph is that the graph can contain +a/+b,
>> but contain no assertions about the set +a+b, and vice versa: the graph can
>> contain assertions about the set +a+b, but not contain any instances
>> identified by +a/+b."
>>
>
> Yes, you are correct, this is the conclusion to which we agreed. If I did
> not reflect that correctly in the revised spec text, that's my fault.
>
>
>>
>> This is not saying that +x/+y/+x+y (nor +x/+y/+y) has to be reintroduced,
>> after we realized, one year ago, that it was not needed. Furthermore, as
>> above clarified the semantics of +x+y, it sounds semantically inconsistent.
>
>
> Again, I was not trying to change the conclusion nor "reintroduce" the
> +x/+y/+x+y logic. I thought it still applied. If it does not still apply,
> let's fix it.
>
>
>>
>>
>>  Note that the current specs are totally based on the golden triangle:
>>>> http://wiki.oasis-open.org/xdi/XdiOne/AddressingAndGraphModel
>>>>
>>>> This way it becomes very difficult - or sometimes even impossible - to
>>>> think at XDI productions in terms of description logic.
>>>>
>>>>
>>> I too am very interested in figuring out how the metagraph model maps to
>>> conventional description logics. But I am not so interested in that topic
>>> that I believe it should delay us issuing XDI 1.0. The practical value of
>>> the metagraph model and in particular the great utility of
>>> restriction/extension of XDI subjects, predicates, and objects is enabling
>>> us to start building some very compelling XDI solutions. I don't know
>>> about
>>> the rest of the XDI TC members, but after six years (2004-2010) of
>>> developing models, it really feels like time to start putting out XDI 1.0
>>> specifications along with real code that shows what can be done with them.
>>>
>>>
>> Most important, I think, is to show is that our specs are solid as rocks,
>> do not contain any bug or logical contraddiction. Either we stay backward
>> compatible with RDF or even if we decide to break compatibility, in any
>> case, we MUST ensure semantic consistency (in addition to syntactic
>> correctness). $is+x, +x/+y/+x+y and +x/+y/+y appears at the moment not
>> consistent with the rest of productions allowed in XDI. This should be fixed
>> BEFORE xdi1.0 specs will be issue.
>
>
> I agree that we want solid, consistent specs. The past year has taught me
> that, as close as the XDI graph model is to the RDF graph model, there are
> still some key differences, and thus I'm no longer even sure what
> "compatibility with RDF" means. I think we can safely say that we can define
> a lossless transformation of RDF graphs/statements into XDI and back, but we
> can't say that there is a lossless transformation of XDI graphs into RDF and
> back. So I"m still perplexed about exactly what we should say about the
> relationship of XDI to RDF.
>
> With regard to the +x/+y/+x+y and +x/+y/+y explanations of the $has$a
> complex metagraph predicate, I think I understand your reasoning for not
> using those explanations.
>
> However, I don't understand the "inconsistency" of $is+x statement.s All we
> have done is defined $is+x to be the inverse of +x. Where is the
> inconsistency? (Feel free to start a new email thread on that topic if it
> would help -- this thread is already quite deep.)
>
>
>>
>>
>>  If that attracts the attention of the DL community and, with their help,
>>> we
>>> figure out there is a better metagraph model, that can become XDI 2.0,
>>> just
>>> as the OWL community has put out OWL 2.0 and the RDF community is now
>>> looking at RDF 2.0
>>>
>>>
>>>
>>>> I think it would be better to rediscuss together the golden triangle, and
>>>> probably revise the current specs page accordingly.
>>>>
>>>>
>>> If you have specific issues that you believe are problems -- especially
>>> fundamental logic or semantics problems -- please do post them together
>>> with
>>> your suggestions about how to fix them.
>>>
>>> Thanks,
>>>
>>> =Drummond
>>>
>>>
>> In order to proceed faster - it would have been better to discuss this, but
>> it is summer times and we all have holidays :-) - if this is ok with you
>> I'll edit the wiki page with definitions of metagraph predicates, their
>> properties and examples of allowed productions which I think could be used
>> without loss of logical consistency.
>
>
> Please do edit the wiki page to provide better definitions of the metagraph
> predicates.
>
> I fear however that the golden triangle will not formally fit these
>> descriptions, therefore I propose to leave it in an INFORMATIVE - NOT
>> NORMATIVE - section of the specs.
>
>
> I'm not sure the golden triangle could ever be anything but informative --
> it graphically explains the origins and physics of each of the predicates
> and predicate combinations in the metagraph model, but the actual definition
> must be given textually (IMHO).
>
> I am curious, however, as to why the golden triangle "will not formally fit
> these descriptions". To me, that would be a big red flag. I personally
> believe that there is more power to the metagraph model than meets the eye,
> and as I said above, I look forward to understanding how it maps to
> conventional description logics.
>
> But it sounds like the best way to proceed is for you to go ahead and edit
> the spec descriptions of the metagraph predicate definitions, and then send
> an email to the list when you are ready and we can all review them. That
> should be a very constructive way to go.
>
> Again, I can't be on next week's telecon (July 15), but I will be on July
> 22.
>
> Best,
>
> =Drummond
>
>
>
>>
>>
>>>  Def. Quota "Drummond Reed" <drummond.reed@xdi.org>:
>>>>
>>>>  I don't think it's any more confusing than "predicate". "verb" is just a
>>>>
>>>>> role - the same XRI could be a subject, verb, and object (especially in
>>>>> an
>>>>> XDI dictionary).
>>>>>
>>>>> But that's just one person's view. What do others think?
>>>>>
>>>>> =Drummond
>>>>>
>>>>> On Thu, Jun 10, 2010 at 2:28 AM, Markus Sabadello
>>>>> <markus.sabadello@xdi.org>wrote:
>>>>>
>>>>>  Oh nooo I'll have to rename lots of stuff in XDI4j :)
>>>>>
>>>>>>
>>>>>> But seriously, isn't "verb" a bit confusing? +name, +address etc. don't
>>>>>> look like verbs to me.
>>>>>>
>>>>>> Markus
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 10, 2010 at 10:49 AM, Drummond Reed <drummond.reed@xdi.org
>>>>>> >wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Thu, Jun 10, 2010 at 12:51 AM, Joseph Boyle <
>>>>>>> boyle.joseph@gmail.com
>>>>>>> >wrote:
>>>>>>>
>>>>>>>
>>>>>>>  On Jun 9, 2010, at 11:22 PM, Drummond Reed wrote:
>>>>>>>>
>>>>>>>> Joseph, first, my apologies for not replying earlier - I had another
>>>>>>>> trip
>>>>>>>> this week so my email is way behind.
>>>>>>>>
>>>>>>>> But we have another XDI TC telecon coming up tomorrow so I wanted to
>>>>>>>> move
>>>>>>>> discussion forward on the individual issues/questions about the
>>>>>>>> example
>>>>>>>> PDX document <http://wiki.oasis-open.org/xdi/PdxExample>. Here are
>>>>>>>> my
>>>>>>>> answers to your two questions about $is (copied from below to keep
>>>>>>>> the
>>>>>>>> thread clean):
>>>>>>>>
>>>>>>>> > 1) How do the two roles of $is form a single coherent concept?
>>>>>>>> Right
>>>>>>>> now the modifier role (as a passive voice marker modifying the
>>>>>>>> following
>>>>>>>> verb) and the standalone role (as the copulative verb) seem like
>>>>>>>> distinct
>>>>>>>> definitions to me. I realize this is analogous to the English verb
>>>>>>>> "to
>>>>>>>> be"
>>>>>>>> that also serves in both these roles, but is there a philosophical /
>>>>>>>> semantic / formal (take your pick) argument that this should
>>>>>>>> logically
>>>>>>>> be
>>>>>>>> the case in XDI?
>>>>>>>>
>>>>>>>> You phrase that question very well. I have been thinking that in the
>>>>>>>> spec, we need to define the semantics for each of the metagraph
>>>>>>>> predicates
>>>>>>>> for each of the following uses:
>>>>>>>>
>>>>>>>> 1) Standalone, e.g., $is
>>>>>>>>
>>>>>>>> 2) As a restriction on another predicate (i.e., preceeding it, e.g.,
>>>>>>>> $is+foo)
>>>>>>>>
>>>>>>>> 3) As an extension on another predicate (i.e., following it, e.g.,
>>>>>>>> +foo$is)
>>>>>>>>
>>>>>>>>
>>>>>>>> Agreed, we must do this, and explain what the 3 usages for a given
>>>>>>>> predicate have in common. (Are these the only 3, or are there even
>>>>>>>> more
>>>>>>>> possible uses?)
>>>>>>>>
>>>>>>>>
>>>>>>>>  I left out the other six options: Using the metagraph predicate as a
>>>>>>> 1)
>>>>>>> standalone subject, 2) subject restriction, or 3) subject extension,
>>>>>>> as
>>>>>>> well
>>>>>>> as a 4) standalone object, 5) object restriction, 6) object extension.
>>>>>>>
>>>>>>> For many of those, the answer may be "undefined", but for some there
>>>>>>> are
>>>>>>> very good answers. For example, $ as a standalone subject is the XDI
>>>>>>> context
>>>>>>> self-descriptor; and $has and $a are both used as the proposed subject
>>>>>>> extensions to create link contracts as shown in the lower part of the
>>>>>>> example
>>>>>>> PDX document <http://wiki.oasis-open.org/xdi/PdxExample>.
>>>>>>>
>>>>>>>
>>>>>>>   I believe the definitions in each of these three roles must be
>>>>>>>> logically
>>>>>>>> consistent. For example, the definition of $is as a standalone
>>>>>>>> predicate is
>>>>>>>> synonymity between the subject XRI and object XRI (they both identify
>>>>>>>> the
>>>>>>>> same logical resource). This is as shown as a reflexive<
>>>>>>>> http://en.wikipedia.org/wiki/Reflexive_relation>arc
>>>>>>>> (self-referential
>>>>>>>> -- originating and terminating in the same node) as
>>>>>>>> illustrated in the golden triangle<
>>>>>>>>
>>>>>>>> http://www.oasis-open.org/committees/download.php/37568/xdi-golden-triangle.png
>>>>>>>> >.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The Golden Triangle diagram (I'm tempted to say the XDI Holy Trinity
>>>>>>>> but
>>>>>>>> should probably refrain) itself shows S and O as separate nodes
>>>>>>>> though
>>>>>>>> connected by arrows labeled $is. For the arc to be reflexive, S and O
>>>>>>>> would
>>>>>>>> have to merge and become a single node. Sorry if this sounds too
>>>>>>>> literal. We
>>>>>>>> do understand "$is" as making S and O equivalent - but this is
>>>>>>>> something
>>>>>>>> that we have to explain with text external to the diagram. Looking at
>>>>>>>> the
>>>>>>>> diagram alone naively, it is not obvious that the $is arcs merge S
>>>>>>>> and
>>>>>>>> O but
>>>>>>>> that the other $a, $has arcs do not make S and P equivalent or P and
>>>>>>>> O
>>>>>>>> equivalent.
>>>>>>>>
>>>>>>>>
>>>>>>>>  I agree that the Golden Triangle diagram by itself does not make it
>>>>>>> clear
>>>>>>> that the $is arc is reflexive. It needs some text with it to explain
>>>>>>> that. I
>>>>>>> have a separate intermediate diagram that explains the origins of the
>>>>>>> Golden
>>>>>>> Triangle diagram that makes that much clearer. I propose we use both
>>>>>>> in
>>>>>>> the
>>>>>>> final spec.
>>>>>>>
>>>>>>>
>>>>>>>  The definition of $is as a restriction on another predicate is that
>>>>>>>> it
>>>>>>>> expresses the inverse of that predicate, e.g., the inverse of +b is
>>>>>>>> $is+b
>>>>>>>> (example: +a/+b/+c <=> +c/$is+b/+a). The logical connection with $is
>>>>>>>> as
>>>>>>>> a
>>>>>>>> standalone verb is that $is, being reflexive arc, is being used to
>>>>>>>> describe
>>>>>>>> the verb it is restricting. As a reflexive arc, it is literally
>>>>>>>> "reversing"
>>>>>>>> the restricted verb. So $is+foo is the reverse (inverse) of +foo.
>>>>>>>>
>>>>>>>> This is one simplest yet most powerful examples of the utility of
>>>>>>>> semantic (non-opaque) identifiers in XDI.
>>>>>>>>
>>>>>>>>
>>>>>>>> > 2) One difference I notice between XDI terminology and linguistics
>>>>>>>> terminology is that in the latter, "predicate" means verb together
>>>>>>>> with
>>>>>>>> object, not simply the verb.
>>>>>>>>
>>>>>>>> Ahhh, I didn't know that. As you know, I have no formal background in
>>>>>>>> either linguistics or formal logic, so I am constantly learning
>>>>>>>> nuances
>>>>>>>> like
>>>>>>>> this. What's the solution: are you suggesting we use the term "verb"
>>>>>>>> instead
>>>>>>>> of "predicate"? As in: XDI subject, XDI verb, XDI object?
>>>>>>>>
>>>>>>>>
>>>>>>>> http://en.wikipedia.org/wiki/Predicate lists the differing meanings
>>>>>>>> in
>>>>>>>> grammar, logic, etc.
>>>>>>>>
>>>>>>>>  XDI gets the term "predicate" from RDF which gets it from
>>>>>>>> mathematical
>>>>>>>> logic, where it specifically means a boolean-valued function. In this
>>>>>>>> case
>>>>>>>> both S and O would be considered arguments to the predicate, and the
>>>>>>>> boolean
>>>>>>>> result True from P(S,O) is expressed by the fact that the predicate
>>>>>>>> is
>>>>>>>> being
>>>>>>>> stated / graphed at all while the boolean result False from P(S,O)
>>>>>>>> would be
>>>>>>>> expressed by not stating / graphing anything. This makes sense in one
>>>>>>>> sense,
>>>>>>>> but may not be the most intuitively obvious meaning, in addition to
>>>>>>>> the
>>>>>>>> conflict with the natural-language grammar that most people are
>>>>>>>> familiar
>>>>>>>> with.
>>>>>>>>
>>>>>>>> I would vote for "verb" not "predicate" in line with the trend
>>>>>>>> towards
>>>>>>>> using simple everyday natural-language-like terms in XDI, which has
>>>>>>>> included
>>>>>>>> using "$is", "$has", "$a" to replace more technical terms. This would
>>>>>>>> be
>>>>>>>> another break with RDF terminology, which may be good or bad
>>>>>>>> depending
>>>>>>>> on
>>>>>>>> your viewpoint. I think some other knowledge representation systems
>>>>>>>> have
>>>>>>>> used "verb" in some way, but don't remember specifically. However,
>>>>>>>> the
>>>>>>>> only
>>>>>>>> programming language I can think of offhand where "verb" is part of
>>>>>>>> normal
>>>>>>>> terminology is COBOL. :/
>>>>>>>>
>>>>>>>>
>>>>>>>>  I agree with your logic, and with using "subject, verb, object"
>>>>>>> instead
>>>>>>> of
>>>>>>> "subject, predicate, object". If anyone on the TC disagrees, please
>>>>>>> post,
>>>>>>> else I will start using that in all the XDI-related text I'm writing.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> =Drummond
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>>
>>
>>
>> ----------------------------------------------------------------
>> Invito da parte dell'Ateneo:
>> Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del
>> tuo aiuto. Dona il  5 x mille all'Universita' di Roma Tor Vergata
>> codice fiscale: 80213750583 http://5x1000.uniroma2.it
>>
>>
>






----------------------------------------------------------------
Invito da parte dell'Ateneo:
Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del
tuo aiuto. Dona il  5 x mille all'Universita' di Roma Tor Vergata
codice fiscale: 80213750583 http://5x1000.uniroma2.it



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