Markus, exactly right - in fact that's a primary use case that was motivating making a clear semantic difference between single-valued and multi-valued contexts. In fact, the server wouldn't even necessarily need to be that smart, because you can put both single-valued and multi-valued contexts of the same type in the same graph. Example:
=!1111$!(+tel)/$is/=!1111+tel$!2
Here the singlar or canonical reference "=!1111$!(+tel)" is just a reference to the second instance in a multi-valued set.
I have more thoughts on how we can use $ cross-references to make singular vs. plural explicit - I'm working on the graph pattern diagrams and will post when ready.
=Drummond
On Sat, Mar 24, 2012 at 7:19 AM, Markus Sabadello <> wrote:
Sometimes a client may just want an email address, and it might not know or care if the context on the server is single-valued or multi-valued.
In this case, I guess it could just ask for
$!(+tel) , and the server could be smart enough to simply return one (the canonical) value, even if there are multiple values stored in a +tel context on the server.
In the past we had a similar pattern, using e.g. +tel$ to request the "canonical" value,
Markus
On Sat, Mar 24, 2012 at 8:16 AM, Drummond Reed <> wrote:
Bill and Giovanni:
Just a note to you both, since you were not able to attend today's call, about agenda item #3 below (RE the latest XDI Graph Patterns doc).
As two of the semantics experts on the TC, I wanted to call to your attention the proposal in this latest version that solves the single-valued vs. multi-valued contexts problem, i.e., can we avoid in an XDI dictionary having to define whether a context intended to represent a literal takes only a single value or multiple values.
For example, it would be ideal if +tel could simply be defined in the dictionary as:
+tel/$is$a/$a$json$string
Note: there would be more statements in the dictionary than this one, e.g., XBNF, human-readable description, labels in various languages, etc. But my point is that it would be ideal if the dictionary definition did not by itself have to say anything about cardinality.
That has not been the case so far, i.e., if you saw the XDI statement =drummond+tel, you don't know whether it is referring to a single instance of a phone number or a set of phone numbers, i.e., whether it is single-valued or multi-valued. That is the equivalent in English of not being able to distinguish whether a noun is singular or plural.
In English, the solution is to do an algorithmic transformation from singular to plural by
adding an "s" (of course there are many exceptions to the rule).
Drummond's phone number <== singular
Drummond's phone numbers <== plural
The proposed solution for XDI semantics is similar, just the other way around:
All XDI "generic nouns" (definitions in the + space) are by definition plural (multi-valued), and there is an algorithmic transformation to make them singular:
+tel <== plural
$!(+tel) <== singular
The origination of the proposal was the realization that if we specified that the $! space identifies ONLY single-valued instances of a class, then all XDI subject addresses that end in a subsegment that begins wtih $! identify literals. Similarly, all XDI subject addresses that end in a subsegment starting with $* would identify ordinals. For example, the following XDI addresses all represent single-valued contexts:
=drummond$!(+tel)
=drummond+address$1+street$!1
=drummond+address$1+street$!2
=drummond+address$1$!(+city)
=drummond+address$1$!(+state)
=drummond+address$1$!(+zip)
Whereas the following represent multi-valued contexts:
=drummond+tel
=drummond+address$1+street
Notice in these examples that an instance of a complex context, like =drummond or +address, is identified with a $number, e.g., $1, $2.
I am enthusiastic that this is a clean semantic solution for distinguishing between single-valued and multi-valued contexts.
Thoughts?
=Drummond
On Fri, Mar 23, 2012 at 10:01 PM, Drummond Reed <> wrote:
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 24 February 2012 USA
Time: 9:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
THE ETHERPAD LINK FOR TODAY IS:
http://xdi.idearpad.org/57
ATTENDING
Mike Schwartz
Drummond Reed
Joseph Boyle
Markus Sabadello
GUESTS
Kari Lippert
Cameron Hunt
1) IDTRUST BUDGET PROPOSAL
Drummond
had a call with the OASIS IDTrust member section staff. This resulted
in revisions to the proposal which we need to review:
http://wiki.oasis-open.org/xdi/IdTrustProposal
Drummond said the key revisions needed were:
Clarification that deployment of the public test servers was a key step towards finishing the XDI 1.0 spec suite.
Clarification on the breadth of involvement of TC members.
Setting
a deliverable date of the end of 2012, producing a final report at that
time, and then optionally applying to renew in 2013.
There was a consensus that the proposal was ready to submit.
# DRUMMOND to send email to Dee.
2) OPEN SOURCE PROJECT UPDATES
Mike
reported that the OpenXDI Project implemented binary storage, so that
if a datatype is specified in the value of the data: URI, then it is now
stored in a binary LDAP node.
Mike
also reported that no code change to OxServer or OxGraph is necessary
to support literal contexts. It will result in a change to OxModel. The
nested roots work is still waiting.
Markus
reported that he's been doing some work on XDI Squared, and is next
looking at implementing it on the Freedom Box, as there is a thread on
the VRM mailing list about p2p usage of VRM.
Drummond
said Phil Windley has published a blog post about how KRL (Kinetic
Rules Language) is going to add XDI support, so that KRL will be operate
on a consistent semantic data interchange layer.
http://www.windley.com/archives/2012/03/krl_data_and_personal_clouds.shtml
This
is very encouraging from both an adoption and engineering standpoint,
as Phil is very well recognized as a technology pioneer.
# MARKUS, MIKE, DRUMMOND to create a page on the XDI TC wiki with a directory of the XDI open source projects.
3) UPDATED XDI GRAPH PATTERN DOCUMENT
Drummond uploaded a new version that solves one additional key issue:
http://www.oasis-open.org/committees/download.php/45530/xdi-graph-patterns-2012-03-22.pdf
The
key issue was how to semantically distinguish single-valued contexts
from multi-valued contexts. This not only makes it possible to
algorithmically compose XDI addresses, but makes XDI dictionary
construction much easier. Drummond showed examples of both single-valued
and multi-valued contexts, and the initial reaction was positive.
4) NESTED ROOT CONTEXTS
Mike asked about the use cases for nested root contexts. Drummond clarified the constraints:
Root nodes can only be subcontexts of other root nodes.
Every local graph still has only one local root node whose XDI address is (). All other root nodes must be nested under this.
The
primary use case is XDI discovery, i.e., the ability to ask one local
graph for metadata about another local graph, e.g., its URI(s). Such
metadata could be considered cached, or it could be fully subscribed,
since it is essentially a remote copy of self-description data.
5) XDI QUERY
Mike
Schwartz and Yuriy Zabrovarnyy sent an email outlining why they don't
believe XML Path & JSON Path are good models on which we should
based XDI Query:
http://lists.oasis-open.org/archives/xdi/201203/msg00036.html
Mike
clarified that having an XDI Path capabiility could be very useful, but
on the client side, not on the server, i.e., it is much more feasible
to implement on a return graph.
It also needs to as efficient as possible on the network.
#
MIKE will post a proposal on the XDI TC wiki and send an email to the
list with a link for discussion. We will make this the focus of next
week's call.
6) NEXT CALL
The next call is next week at the regular time.
