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