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

*Subject*: **Re: [xdi] Proposal for separation of subject/predicate and parent-subject/child-subject semantics**

*From*:**Drummond Reed <drummond.reed@xdi.org>***To*: Giovanni Bartolomeo <giovanni.bartolomeo@uniroma2.it>*Date*: Thu, 22 Apr 2010 08:54:49 -0700

This thread is missing the point I made in my reply yesterday, which I definitely want to discuss on today's telecon.

The point is that, as now proposed:

+a/$has/+b <=> +a/+b

+a/$has$a/b <=> +a+b

However neither of these implies the other. In other words

+a/$has/+b != +a/$has$a/+b

+a/+b != +a+b

I can show this logically with this proof:

1) $has as a predicate is an assertion that its object is a predicate of its subject, e.g. +a/$has/+b is asserting that the subject +a has the predicate +b. It thus implies logically that +a/+b AND asserts that the XDI statement +a/+b exists in the XDI graph where the +a/$has/+b statement exists.

So the OBJECT of a $has metagraph statement is by definition a PREDICATE.

2) $a as a predicate is the assertion that its object is the object of a predicate that is its subject, e.g., +a/$has$a/+b means that +a is a predicate and +b is an object of that predicate. And

So the OBJECT of a $has$a metagraph statement is by definition an OBJECT.

Since a PREDICATE is not an OBJECT, the two statements are not logically equivalent. And neither by itself in the graph implies that the other exists in the graph.

I have spent the last two months thinking through the implications of the path where +a/+b implies +a+b and vice versa, and I am convinced it does not work.

What +a/$has$a/+b defines in

That set - consisting of a single object - is NOT equivalent to the set identified by +a/$has/+b, which implies +a/+b, which identifies the XDI graph of all objects that are the object of the predicate +b on the subject +a. That set is by definition zero-to-n, and thus cannot be either logically or resolution equivalent to +a+b.

=Drummond

On Thu, Apr 22, 2010 at 3:08 AM, Giovanni Bartolomeo <giovanni.bartolomeo@uniroma2.it> wrote:

Yes, that's correct. The "magic" you are referring is called "reasoner" and should be placed at the XDI endpoint which receives the incoming query.

As a side note, the difficulty about implementation is not to implement the reasoner itself (there are already available products, open source, in java) rather, to provide a formal, *consistent* model for XDI documents and XDI query which could be described to the reasoner in terms of Description Logic.

Talk with you all in today's phc,

Kind Regards,

Giovanni

Def. Quota "Markus Sabadello" <markus.sabadello@xdi.org>:

Okay I understand.. And you call this behavior "logical equivalence", right?

Whereas "resolution equivalence" is based on $is statements?

So from your point of view, both "logical equivalence" and "resolution

equivalence" would affect how an XDI endpoint works, i.e. add some "magic"

to the plain data in a low-level XDI store/document?

Markus

On Thu, Apr 22, 2010 at 11:06 AM, Giovanni Bartolomeo <

giovanni.bartolomeo@uniroma2.it> wrote:

Thank you Markus and Drummond for your replies.

I think Markus got the point. Here our views are probably different here.

My answer to Markus is that this query

=markus

should return$get

/

=markus+email

=markus+email

$1

"markus.sabadello@gmail.com"

This might be not an asserted statement (there is no need that a human

writes this in the document) but an inferred one (a reasoner produces this).

In this, my opinion is that XDI should behave more similarly to RDF/OWL

rather than to XML (i.e. XDI is more an ontology language rather than a

simple markup language).

As Bill pointed out that +a <=> (+a), I'm saying that there are also other

logical equivalences and that +a/+b <=> +a+b is one of them (and that's why

I see no need for $has$a) - sorry, I'm disagreeing here with you Drummond.

But you're probably right in saying that I'm not fully understanding what

you're proposing ("semantically linked" and the golden triangle). So looking

forward to talk with you for a clarification on this.

Kind Regards,

Giovanni

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

It's late so I will just put short replies inline.

On Wed, Apr 21, 2010 at 9:11 AM, Markus Sabadello

<markus.sabadello@xdi.org>wrote:

So if I send the following XDI message to an endpoint:

=markus

$add

/

=markus

"markus.sabadello@gmail.com"

and then I send this XDI message:

=markus

$get

/

=markus+email

What will be the XDI response?

Markus

Markus, my answer is that the answer to the query (your second message)

would be no such subject exists (in other words, the response would be

null). In order to get a response to the second query, you would have to

first made this operation:

=markus

$add

/

=markus+email

...

where ... is whatever the contents of the subject =markus+email is.

Giovanni,

I understand what you are saying below, but you may not understand what I

am saying. I am saying that +a/+b and +a+b are neither logically

equivalent

or resolution equivalent.

I am only saying that they are *semantically linked* - in other words,

that

if you have +a/+b in the graph, it implies that +a+b would be a

semantically

valid XRI in the graph, and vice versa. However it does NOT imply that

+a+b

exists, or vice versa.

The reason this is semantically consistent -- and I agree with you that of

course XDI needs semantic consistency -- is because in the analysis I have

been doing of the implications of what it would mean IF +a/+b and +a+b

were

logically equivalent, I keep finding deeper and deeper problems.

I don't have time to go into in more deeply now, but I would summarize

that

the golden triangle model I posted yesterday reveals the crucial

difference

between $has, as a predicate that identifies another predicate, and $has$a

as a predicate that identifies an object.

Because of this, $has and $has$a, as now proposed (vs. some of the

discussions of this topic over the last year that you reference below) are

not logically equivalent, and thus obviously not resolution equivalent

either.

Let's definitely make this the subject of tomorrow's XDI TC telecon.

Talk to you then,

=Drummond

On Wed, Apr 21, 2010 at 11:10 AM, Giovanni Bartolomeo <

giovanni.bartolomeo@uniroma2.it> wrote:

Hello Markus and Drummond,

thanks for your replies. I think there is however some confusion which I

want to clarify once for all. I'm not saying that +a/+b is resolution

equivalent to +a+b. I think we are now all agreeing on this (at least I

think :-).

Logical equivalence is a different concept. It means that if +a/+b is

resolvable then also +a+b must be. Note that they DO NOT resolve to the

SAME

node (this is instead resolution equivalence).

The requirement I'm talking about (if +a/+b is resolvable then also +a+b

must be and viceversa) is needed to ensure consistency in my semantic

model.

For instance, having in a graph

=example

$has

will allow to deal with =example+email as the set of emails which

=example

owns (=example+email), and consequently make assertions on them (pls

refer

to http://lists.oasis-open.org/archives/xdi/201004/msg00004.html for

details on this, btw I can clarify them in next phc). This is also

highlighted in point 1) of

http://lists.oasis-open.org/archives/xdi/201003/msg00014.html.

Note that resolution of certain statements is needed, even if not

asserted

in the graph, but inferred using a reasoner (again pls refer to my mail

for

details) in order to implement what we have discussed in

http://lists.oasis-open.org/archives/xdi/201001/msg00047.html

=bill.barnhill: We can get the graph containing statements about any

statement in the graph, and that graph will only exist if and only ifis

thegiovanni: resolution = your statement is true; fault = your statement

statement is in the graph. put more simply (+a/+b) is resolvable, or

R(+a/+b) = True. Generalizing this we see that if R(X) = True then

R((X)) =

True, meaning and (X) are logically equivalent

Drummond: It seems the import of what you are saying is that +a <=>

(+a)

false

=bill.barnhill: but not +a = (+a)

Drummond: Yes!address

Drummond: A $is statement in an XDI graph establishes what Bill callswhere we used symbol <=> to address logical equivalence, and = to

"resolution equivalence"

resolution equivalence.

Now my point is: either the TC has a different semantic model to propose

for XDI (in this case, I would be glad to know more and discuss about

it),

or the TC wants to discard semantic consistency for XDI. If the latter

is

the case, then, frankly, I think the TC is underestimate a tremendously

powerful feature which could instead change the whole concept of web

applications in next few years. Please let me know your opinion about

it.

Thank you,

Giovanni

Def. Quota "Markus Sabadello" <markus.sabadello@xdi.org>:

What I'm afraid of is that people will never understand resolution

equivalence, and that it would be difficult to implement at the storage

and

messaging levels of an XDI stack.

Can't we just have logical equivalence without resolution equivalence?

On the logical level a high level application/reasoner/etc can infer

lots

of

stuff based on some $is, $has, $is$a, etc rules we make up, but I'm

really a

bit scared of having to implement such extra XDI "magic" just for plain

XDI

storage and messaging..

Markus

On Tue, Apr 20, 2010 at 5:21 PM, Giovanni Bartolomeo <

giovanni.bartolomeo@uniroma2.it> wrote:

Dear Drummond, All,

thank you for this proposal - two main thoughts from my side:

1) it is FUNDAMENTAL that if +a/+b is resolvable then also +a+b MUST

be,

and viceversa. We used the symbol <==> to say this, +a/+b <==> +a+b.

Obviously the stored document can only contain one of the two, e.g.

the

document only contains +a/+b, but +a+b MUST be resolvable as well.

This is about the relationship between asserted and inferred

statements

which I illustrated in the second part of my email

http://lists.oasis-open.org/archives/xdi/201004/msg00004.html - we

didn't

discuss this yet because we ran out of time last week, but it would be

good

to address this in next phc.

2) About the following statements (in which the symbol <==> is used in

a

somehow different way than in point 1)

+a/$has/+b <==> +a/+b

+a/+/+b <==> +a+b

+a/$/$b <==> +a$bto

+a/=/=b <==> +a=b

+a/@/@b <==> +a@b

+a/*/*b <==> +a*b

+a/!/!b <==> +a!b

+a/()/(b) <==> +a(b)

note that the statements on the left side in their own give origin

metastatements like +a/$has/+, +a/$has/$, +a/$has/() which in turns

are

logically equivalent to +a+, +a$, +a() whose semantics is totally

unknown to

me.

Kind Regards,

Giovanni

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

Per my action item from Thursday's telecon, following is more about

my

analysis and proposal for solving the "$has semantics problem" once

and for all.----------------------------------------------------------------

*** ANALYSIS ***

My first conclusion, on which I think we all agree, is that while

+a+b

might imply +a/+b and vice versa, that does not mean that: a) they

have the same semantics, or b) that they identify the same XDI graph.

Indeed, since one is an XDI subject and the other adds an XDI

predicate, by definition they cannot identify the same XDI graph.

To illustrate in English, most English verbs can be made into nouns

by

putting them in their infinitive form (“to be”, “to run”, “to

shout”).

But “run” and “to run”, while clearly linked semantically, do not

have

the same meaning. They cannot be interchanged with each other.

Thus my second conclusion is that none of the three XDI graph

examples

we were discussing on our telecon two weeks ago were in fact

equivalent. They were each different XDI graphs that had similar but

not identical semantics.

My third conclusion is that this means that we do in fact need

clearly

distinguished ways of semantically and syntactically of expressing

that an XDI subject (e.g., +a) : 1) has a child subject (e.g., +a+b),

and 2) has a predicate (e.g., +a/+b).

My fourth conclusion was that this is the problem we have been

struggling with for the last year: by using $has (with or without

variants like $has$a) to express both parent subject/child subject

relationships (+a+b) and subject/predicate relationships (+a/+b), we

have wrapped ourself in a classic Gordian knot.

*** PROPOSAL ***

Once the problem was framed this way, it became much easier (for me

anyway) to see that a clean solution would be to dedicate the $has

predicate to only one semantic – either the parent subject/child

subject relationship or the subject/predicate relationship. Of those

two options, I strongly prefer dedicating the $has verb to expressing

the subject/predicate relationship (+a/+b), since this is the simpler

and more intuitive to understand, and mirrors the semantics of the $a

predicate, which expresses predicate/object relationships.

If $has is dedicated to that expression, then we simply need a

different predicate (or set of predicates) to express parent

subject/child subject relationships.

For that, an obvious answer is to use XRI delimiters as predicates.

This is intuitive since it is syntactically required to have a

delimiter between XRI subsegments, and each of the six XRI delimiters

(not counting parentheses for cross-references) has its own

XRI-defined "semantics", e.g., * means reassignable identifier, !

means persistent identifiers, etc.

So to summarize using +a and +b notation:

+a/$has/+b <==> +a/+b

+a/+/+b <==> +a+b

+a/$/$b <==> +a$b

+a/=/=b <==> +a=b

+a/@/@b <==> +a@b

+a/*/*b <==> +a*b

+a/!/!b <==> +a!b

+a/()/(b) <==> +a(b)

Semantically, it would still be true that +a+b/$is$a/+b (and the

inverse that +b/$a/+a+b). And while +a+b would imply that +a/+b is

valid, and vice versa, the existence of one in an XDI graph would not

imply the existence of the other.

So, if =example wanted to do a query to determine if +a+b and +a/+b

both existed in an XDI graph, it would be:

=example

$get

/

+a

$has

+b

+

+b

I have been trying out this proposal in sample XDI documents for the

past week and it seems to work very well. Please consider and

experiment with it and post your thoughts. We'll put it on the agenda

for next week's telecon.

=Drummond

---------------------------------------------------------------------

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.

---------------------------------------------------------------------

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.

---------------------------------------------------------------------

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.

**References**:**Proposal for separation of subject/predicate and parent-subject/child-subject semantics***From:*Drummond Reed <drummond.reed@xdi.org>

**Re: [xdi] Proposal for separation of subject/predicate andparent-subject/child-subject semantics***From:*"Giovanni Bartolomeo" <giovanni.bartolomeo@uniroma2.it>

**Re: [xdi] Proposal for separation of subject/predicate and parent-subject/child-subject semantics***From:*Markus Sabadello <markus.sabadello@xdi.org>

**Re: [xdi] Proposal for separation of subject/predicate andparent-subject/child-subject semantics***From:*"Giovanni Bartolomeo" <giovanni.bartolomeo@uniroma2.it>

**Re: [xdi] Proposal for separation of subject/predicate and parent-subject/child-subject semantics***From:*Markus Sabadello <markus.sabadello@xdi.org>

**Re: [xdi] Proposal for separation of subject/predicate and parent-subject/child-subject semantics***From:*Drummond Reed <drummond.reed@xdi.org>

**Re: [xdi] Proposal for separation of subject/predicate andparent-subject/child-subject semantics***From:*"Giovanni Bartolomeo" <giovanni.bartolomeo@uniroma2.it>

**Re: [xdi] Proposal for separation of subject/predicate and parent-subject/child-subject semantics***From:*Markus Sabadello <markus.sabadello@xdi.org>

**Re: [xdi] Proposal for separation of subject/predicate andparent-subject/child-subject semantics***From:*"Giovanni Bartolomeo" <giovanni.bartolomeo@uniroma2.it>

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