Re: [xdi] Short paper on XDI and Named Graphs (was: Re: [xdi] LatestXDI Graph Patterns and Statements docs with key revisions)

[Drummond Reed <drummond.reed@xdi.org>]

Giovanni,

Nice work! It's delightfully short and makes very clean and salient points about how XDI and RDF Named Graphs can fit together.

Thanks for sharing it.

See also my next message about the TC telecon this week.

Best,

=Drummond

On Wed, Apr 27, 2011 at 6:00 AM, Giovanni Bartolomeo <giovanni.bartolomeo@uniroma2.it> wrote:

Dear All,

I've uploaded a new paper describing how XDI and Named Graphs could work together to provide lots of benefits to Linked Data.

Though very short, this paper is an attempt to summarize my view about the relationships between XDI, XRI3.0, Named Graph, and HTTP focusing in particular on the issues of "cross references" and "HTTP resolution". To me these concepts represent the very key to interoperability with the existing semantic infrastructure.

The paper has been accepted for poster presentation at ESWC 2011.

Best Regards,
Giovanni

Def. Quota "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

----------------------------------------------------------------
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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php