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: Short paper on XDI and Named Graphs (was: Re: [xdi] Latest XDIGraph Patterns and Statements docs with key revisions)

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,

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

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