← Prev in month ← Prev in thread
Next in thread → Next in month →

Minutes: XDI TC Telecon Thursday 1-2PM PT 2010-04-15

From
Erummond Qeed
Date
2010-04-17T14:54:13+00:00
ID
Thread
Minutes: XDI TC Telecon Thursday 1-2PM PT 2010-04-15
Following are the minutes of the unofficial telecon of 
the XDI TC
at:

Date:  Thursday, 15 April 2010 USA

Time:  1:00PM - 2:00PM Pacific Time (21:00-22:00 UTC)

ATTENDING

 

Giovanni
Bartolomeo

Markus
Sabadello

Drummond
Reed

John Bradley

 

GUEST

Joesph Boyle

AGENDA

 

1) DISCUSSION/PROPOSAL FOR SOLVING "THE PROBLEM FORMERLY KNOWN AS $HAS
SEMANTICS"

 

First, Giovanni
went over the email he sent as an action item from two weeks ago:

 

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

 

He explained
that of the two examples below, he preferred example #2 because using $1
 as a
predicate (e.g., as an index into an array) makes the most sense to him.

 

EXAMPLE #1

 

=example

      +email$1

            “”

 

EXAMPLE #2

 

=example+email

      $1

            “”

 

Giovanni
didn’t think that the predicate +email$1 made sense in a global context 
because
it was essentially proposing a instance of a class.

 

Drummond
felt that +email$1 was the equivalent of saying “the first email”, i.e.,
 it is
a generic concept until it is applied to a specific subject, at which 
point it
would mean, “=example’s first email”, and thus point to a specific 
instance.

 

Giovanni
pointed out that as currently defined, +email$1 semantically means
“+email/$has/$1”. 

 

Drummond
explained that this was what he now believed was the root of the “$has
semantics problem”, which has been a persistent issue for the last year.
 In
thinking about this problem over the last two weeks, he concluded the 
root of
the issue is that for both practical graph inspection/resolution 
purposes, as
well as semantic purposes, we need a clear, semantically unambiguous way
 to
differentiate between:

 

1) Parent/child
relationships between XDI subjects, e.g., +a+b

 

2) Subject/predicate
relationships, e.g., +a/+b.

 

One way to
do this is to dedicate $has semantics to expressing only one of the two
relationships above, and to define a different mechanism for expressing 
the
other one.

 

Since the
core metagraph concept of $has is to describe an outgoing arc from a 
subject,
Drummond proposed dedicating +a/$has/+b to expressing +a/+b. This means 
we need
a different way to express parent-child relationships between XDI 
subjects. For
that, Drummond proposed using XRI subsegment delimiters as predicates, 
with
each delimiter being the predicate that expresses the relationship 
between the
parent subject and all child subjects that use that delimiter type. For
example:

 

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

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

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

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

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

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

 

Giovanni
asked if +a/$has/+b <==> +a/+b still implied +a+b. 

 

 

Drummond
said he believed that +a/+b would still imply that +a+b is valid, and 
vice
versa, however from a resolution standpoint, the presence of one in the 
graph
would not imply the presence of the other. For example

 

=example

      +email$1

 

does not
imply that =example+email$1 exists in the same graph, and vice versa. 

 

Drummond
said that, while semantically linked, the two are separate statements. 
In
English it is like the difference between a verb and the infinitive form
 of a
very in English, e.g., "run" and "to run".

 

Joseph asked
what would be the actual English translations of +a/+b and +a+b? Or to 
use more
concrete examples, =drummond/+email and =drummond+email?

 

Drummond
said =drummond/+email would be "Drummond has emails" and
=drummond+email would be "Drummond's emails". In other words, the
first expresses a subject-predicate relationship, while the second is 
simply a
subject.

 

# DRUMMOND
to send an email to the list with more details about this proposal.

 

 

2) X3J (X3
FOR JSON) SERIALIZATION FORMAT PROGRESS

 

We did not
have time to go into this further but the priority still remains for 
this new
JSON serialization format to be completely defined so that interoperable
implementations can be built and tested.

 

 

3) NEXT CALL

 

The next call is next week at the regular time.
← Prev in month ← Prev in thread
Next in thread → Next in month →