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: Minutes: XDI TC Telecon Thursday 1-2PM PT 2010-04-22


Following are the minutes of the unofficial telecon of the XDI TC at:

Date:  Thursday, 22 April 2010 USA
Time:  1:00PM - 2:00PM Pacific Time (21:00-22:00 UTC)

ATTENDING

Bill Barnhill
Giovanni Bartolomeo
Markus Sabadello
Drummond Reed
John Bradley

GUESTS

Joe Boyle


AGENDA


1) X3J (X3 FOR JSON) SERIALIZATION FORMAT PROGRESS

  http://lists.oasis-open.org/archives/xdi/201002/msg00027.html

Bill reported that, although he hasn’t had much time, he has checked
into it, and he’s writing a new version from the ground up.

2) PDX PROJECT

Drummond explained that the project he referred to several calls ago
now has the working acronym PDX (Personal Data Exchange), and involves
six different companies that want to build a network of personal data
stores (PDS) interlinked using XDI. Drummond, Markus, and guest Joseph
Boyle have been working on a sample PDX XDI document, a working draft
of which is available at:

 http://whisperproject.org/mediawiki/index.php?title=PDS_XDI_Document

There is an initial meeting of the PDX founders next week after the
Kynetx Impact Conference (which is why Drummond can’t attend next
week’s telecon). Drummond will give an update on the call the week
after next.

3) $HAS AND $HAS$A

We continued discussion of this thread:

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

First, there was complete consensus that we want to have solid
consistent semantic model that is described by a Description Logic. So
the issue under discussion is simply what the semantics are of the
proposed $has and $has$a statements (see the email thread linked
above).

Drummond explained that his conclusion was summarized by saying that:

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

Giovanni asked if what Drummond meant is that not every +a/+b  gives
origin to +a+b. Drummond said yes, that was what he meant.

Giovanni asked if the viceversa held, i.e. if I have +a+b, does  this
imply +a/+b? Drummond was not sure about that yet - he needed to think
about it.

Giovanni said his understanding that +a+b is representing the set of
all objects whose subject is +a and predicate is +b. Drummond said
that to be more precise,  +a/+b identifies the members of the set of
all objects that are objects of the predicate +b on the subject +a.

Giovanni asked, "But what if I need to use it as a subject in a statement?"

Drummond said that is a really good point. If you want to identify
that set as a subject, he agrees with Giovanni that +a+b as the
identifier of that set. To quote Giovanni, "That's why I believe that
+a+b is representing the set of all objects whose subject is +a and
predicate is +b."

Bill then wrote the following:

+a/+b = set of all object values for that s, p
+a+b is set of all properties of the subclass of property +b
constrained to have a domain +a. One property of this subclass is the
statements in which that property is used, which is related to +a/+b.

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.

Giovanni then said (exact quote from IM): "Finally!!! you got it Drummond!!!"

Giovanni suggested that this agreement is an important milestone for
XDI. Drummond agreed and pointed out the great irony that the
semantics of $has and $has$a are now the exact opposite of what they
have been for the past year (as recorded in our wiki spec at
http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel). Drummond
acknowledged the great service Giovanni had done in alerting the TC to
this flaw in the semantics and persisting until we unearthed the
solution. Drummond suggested we should update the wiki spec quickly
with this new consensus so that it remains an accurate reflection of
what we plan to put in the 1.0 spec.

*********

We next discussed Bill's suggestion in email of a $ask predicate that
would be like $get except it would explicitly ask the XDI endpoint to
do semantic reasoning over the target XDI graph. In other words, it
would retreive a statement from a graph that is not strictly
resolveable but is inferred.

Giovanni supplied the following example:

ASSERTED STATEMENTS:

=example+mail
    $1
        "example@example.com"

INFERRED STATEMENTS

=example
   +mail
       "example@example.com"

Markus says he'd like to have reasoning capability of an XDI endpoint
be a capabilty that could be turned on and turned off. There was
consensus that having XDI endpoints be able to self-describe their
capabilities. Bill suggested that we may want to require a certain
very basic reasoning capability for all XDI endpoints, and then have
higher levels that could represent different powers of Description
Logics.

Drummond agreed because he had been assuming that all XDI endpoints
would be able to calculate (infer) $has and $has$a statements - this
would be a good capability to have in the core.

Joseph asked if Bill had some references he could share for learning
about the levels of reasoning supported in other knowledge
representation systems, and that could help compare to what we have or
want for specifying XDI reasoning capabilities.

Bill said he had been giving training on that topic recently and would
send a set of links to the list.

# BILL to send links on semantic reasoning and DLs to the list.


4) NEXT CALL

There will NOT be a telecon next week due to the PDX founders meeting
Drummond will be attending. The next call will be in two weeks at the
regular time.


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