Re: [xdi] Latest XDI Graph Patterns and Statements docs with keyrevisions

["Giovanni Bartolomeo" <giovanni.bartolomeo@uniroma2.it>]

Dear Drummond,

I've taken some time to read your proposal, however I'm not sure that  
having one canonical address is a good thing, at least in practice.

In my opinion this might discourage legacy ontologies to merge  
together, as they should be rewritten to adapt their XRIs to canonical  
XRIs (instead of simply stating that the resources there described are  
the same as others defined somewhere else - as it happens in Linked  
Data).

Also I'm not sure it is correct to transfer attributes defined for one  
XRI to another XRI (even if they have been stated to be synonyms)  
because the second is the "canonical one". This way we attribute the  
"canonical node" all the property stated for its synonyms, whereas it  
could be useful to keep them separated (to distinguish authoritative  
from non authoritative statements on a given resources).

Obviously we need to discuss this... meanwhile, please find some more  
detailed comments below.

Kind Regards,
Giovanni

Def. Quota "Drummond Reed" <drummond.reed@xdi.org>:
> The suggestion on the call was to represent the graph as a multigraph (
> http://en.wikipedia.org/wiki/Multigraph), i.e., allow multiple arcs between
> one parent node and one child node. However there are two drawbacks to this
> approach:
>
>  1. It breaks the "one XDI statement per XDI graph arc" rule that is
>  currently leads to such a clean JSON serialization of an XDI graph and vice
>  versa.

I don't see this to be a problem. If you need to preserve the "one XDI  
statement per XDI graph arc" rule (btw, is there any need except the  
fact that we have assumed this to develop our json notation?), it is  
enough to think that many (same as the number of statements you have)  
self referential arcs are on that node. The fact that there is still  
just one node isn't an argument I think, because this situation occurs  
also for other scenarios (for example, any reflexive property implies  
a statement like this: +mynode/+myreflexproperty/+mynode which clearly  
involve a self reflexive arc)

>  2. It leads to what I call "synonym explosion".
>
> To illustrate synonym explosion, imagine an XDI graph where the first
> context node below the root context node has 3 synonyms from the root
> context node, a second context node below the first context node has 3
> synonym arcs from the first context node, and a third context node below the
> second context node has 3 synonym from the second context node.
>
> That means:
>
>  1. The first context node has 3 unique XDI addresses.
>  2. The second context node has 9 unique XDI addresses.
>  3. The third context node has 27 unique XDI addresses.
>
>
> This would lead to disaster when it comes to being able to determine
> equivalence between two XDI addresses.

I don't see any computational disaster here, having such a graph  
allowing to split the process of determining equivalence in just three  
passages (one per node), same as if there were one different node per  
synonym as you propose.

>
> However there is a simple solution that prevents synonym explosion while
> still establishing synonyms as full equivalence relations. The first rule
> would be to NOT have the XDI graph be a multigraph -- in other words, to
> keep the one-arc-per-XDI statement rule--and require all synonyms to be
> expressed as a single $ relational arc from one synonym to another. The
> second rule is that any XDI context node that has a $ relational arc MUST
> NOT the the origin of any other arcs. In other words, a $ relational arc
> effectively terminates the XDI graph at the source context node and
> redirects any deeper addressing to the target node. The unique XRI
> identifying the target node can be called the canonical address of that
> node.
>
> This rule allows the XDI address of any context node to be canonicalized
> into a single XRI, reducing the 27 unique addresses above to a single
> canonical address.
>
> ROOT CONTEXT ADDRESSING
>
> The second issue is how to address the root context node. Given the synonym
> solution above, it follows that a root context node cannot be identified via
> a synonym because it is already canonical. Thus the only way it can be
> identified is through a cross-reference from another context.

Obviously this depends on the choise made about synonyms: in my  
opinion, the root context node is a context node as other context  
nodes, as such it might be addressed from another context; if there  
are synonyms for that root context node, then they will be represented  
as arcs incoming to that context node.

I agree instead that we need a unique way to address the root context  
from within a context, some weeks ago I proposed the $ word $this and  
Bill proposed the word $self, which is probably equivalent to () in  
your notation.

> cross-reference is an incoming contextual arc from the other context, it
> means the only valid way to express a root context address is an XDI
> statement in the form:
>
>    ()/$()/(cross-reference-here)
>
> This reads: "The root context of this XDI graph is considered a subcontext
> of another XDI graph in a different context".
>
> The examples I provided in the XDI Graph Patterns document are:
>
>    ()/$()/(http://example.com/ox/=!0999.a7b2.25fd.c609)
>
>   ()/$()/(=!0999.a7b2.25fd.c609)
>
> In the first case, the value of the XRI cross-reference would be the
> equivalent of the URI identifying an RDF named graph. In the second case,
> the value is only an XRI i-number which must be resolved into a URI. The
> standard form of that statement (using $uri as a complex predicate) would
> be:
>
>   (=!0999.a7b2.25fd.c609)$uri/+http/!1
>   (=!0999.a7b2.25fd.c609)$uri/!1/(data:,
> http://example.com/ox/=!0999.a7b2.25fd.c609)
>
> This also resolves our open questions about XDI context discovery: the
> process of discovering an XDI endpoint from an XDI context address is just a
> matter of making a query for the complex property above.
>
> Hope this helps,
>
> =Drummond (with a reminder that I'm travelling this week, so we won't be
> having an XDI telecon this Thursday)
>



----------------------------------------------------------------
Invito da parte dell'Ateneo:
Il tuo futuro e quello della Ricerca Scientifica hanno bisogno del
tuo aiuto. Dona il  5 x mille all'Universita' di Roma Tor Vergata
codice fiscale: 80213750583 http://5x1000.uniroma2.it