Re: golden triangle (was Re: [xdi] $is is the universal inverse restrict

Subject: Re: golden triangle (was Re: [xdi] $is is the universal inverse restriction)

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

xdi message