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: [xdi] $is is the universal inverse restriction




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. 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.

 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 arc (self-referential -- originating and terminating in the same node) as illustrated in the golden triangle.

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 




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