xdi message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Minutes: XDI TC Telecon Friday 2012-12-14
- From: Drummond Reed <drummond.reed@xdi.org>
- To: OASIS - XDI TC <xdi@lists.oasis-open.org>
- Date: Fri, 14 Dec 2012 11:22:44 -0800
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 14 December 2012 USA
Time: 9:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
ATTENDING
Les Chasen
Markus Sabadello
Drummond Reed
Phil Windley
GUESTS
Animesh Chowdhury
THE ETHERPAD LINK FOR TODAY IS:
AGENDA
***** NEWS & UPDATES *****
None scheduled.
***** PRESENTATIONS/DISCUSSIONS *****
--- DECLARATIVE XDI POLICY STATEMENTS (DRUMMOND & MARKUS)
See the most recent discussion comments (at the top of the page). This is not yet a formal proposal, but it represents potentially an important breakthrough in link contracts and policy _expression_/evaluation.
We reviewed the examples provided at the top of the page. Markus explained the relevance of query operators like $equals, $greater, and $lesser for both link contract policies and queries.
Phil suggested that languages like KRL would offer a higher level interface and then compile policies into XDI link contracts.
# DRUMMOND to move this into a proposal after receving any feedback from other TC members on the list.
***** DECISION POINTS FOR THIS CALL *****
This week's decision queue is the following set of proposals:
--- EQUIVALENCE LINKS AND $REF RESOLUTION (DRUMMOND & MARKUS)
IMPORTANT: This proposal has been updated to reflect the discussion on the list this week. It now proposes two different XDI verbs - $ref and $is - for equivalence links. See the updated proposal page for the full description.
Although Giovanni was not able to attend the call, on the mailing list he sent a reference to a paper about RDF sameAs that was submitted for the W3C RDF conference a few years ago.
We noted that we discussed the paper at that time, and it had many good insights.
# DRUMMOND to review RDF sameAs paper and add commentary to the Discussion page.
Markus mentioned that the Higgins Project also defined a different form of equivalence called higgins:correlation that stated a weaker form of equivalence.
We discussed the terminology used in the proposal. Markus suggested that it would be better to talk about canoncial and non-canonical equivalence (vs. identifier and entity equivalence). Markus also suggested "substitution" and "non-substitution" links.
# DRUMMOND to update the proposal to use new terminology.
We then discussed inverse arcs ($is prefixes). Markus asked whether it is the server's responsibility to make $is inferences automatically. An example is, if the following statement existed in the graph:
The inverse of this statement is:
Then, if the server received a $get request for:
...should the server follow the inference from each +friend statement that references =animesh?
Drummond agreed this is an excellent question, and noted that there are at least two parts to the answer:
1. Does the relevant link contract allow inverse statements to be inferred?
2. Should the endpoint infer the $is relations automatically?
With regard to the second question, Markus felt that the endpoint should be allowed make the inferences automatically. Drummond agreed that the capability should be allowed - even encouraged - but that we have to be very careful about the privacy issues.
Markus speculated whether explicit inverse statements would actually be needed in the graph.
We discussed the cases where inverse statements would be valuable, for example if a program needs to discover the relations that point to a specific node ("backlinks"). However Drummond pointed out that these backlink inferences can always be algorithmically generated for any XDI graph.
Drummond returned to the privacy issue and gave an example. Say a link contract gave authority X access to subgraph A and not subgraph B, but subgraph B contains relations to subgraph A. Therefore subgraph A has inferred inverse relations with subgraph B. Should those inferred relations be something that X has access to? From a privacy perspective, the answer is no, unless a link contract specifically allows such access. He noted that this is EITHER a use case for inverse links being specific, OR a use case for link contract policies to be able to explicitly control access to inverse inferences.
We then discussed a use case where an inverse statement is needed explicitly: when an indivdiual wants to assert in their own personal graph that they are the employee of an organization. For example:
This discussion about inverse relations and inferences is relevant to certain link contract policy examples, e.g. when stating that a message should be allowed if it comes from an employee of Neustar:
...$do$if/$true/(($from)/$is+employee/@neustar)
Is the above the same as the following?
...$do$if/$true/(@neustar/+employee/($from))
Drummond noted that what appears to be the "safe" route from a policy evaluation standpoint is to NOT automatically make inverse inferences, but do keep inverse relations explicit.
Drummond suggested that there are use cases for both situations: requiring inverse relations to be explicit, and allowing an endpoint to compute them algorithmically. He speculated therefore that neither can be the default.
Markus realized that link contract policies could be written to express the precise directional relation needed for verification, which helps avoid the issue.
Drummond suggested that what may be required for link contract policies is a context or operator that explicity instructs the endpoint to automatically compute inverses when evaluating the policy statement. An example might be:
...$do$if/$true$or$is$true/(($from)/$is+friend/=!1111)
That policy statement would evaluate to true if either the statement OR its inverse were true. By contrast...
...$do$if/$true$and$is$true/(($from)/$is+friend/=!1111)
...would evaluate to true only if both the statement AND its inverse were true.
Another way to express the latter might be.
...$do$if/$true$all/(($from)/$is+friend/=!1111)
Drummond pointed out that the power of declarative policy statements is that they can check for the existence of one precise arc in the graph. This would argue heavily in favor of inverse arcs being explicit when needed.
***** DECISION POINT QUEUE REVIEW *****
The decision queue stack is now shown on the following three auto-generated Category pages:
See also this list of proposals that need to be developed:
***** NEXT CALL *****
Since next Friday is the final day before the Xmas break, we are not sure about a call next week. Drummond will send an email next Thursday about call status. We will not have a call the following week in observation of the holiday break.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]