Re: [xdi] Quick note about "crawling" public link contracts

On Thu, Dec 19, 2013 at 6:40 PM, Drummond Reed <drummond.reed@xdi.org> wrote:

That's a good point, Markus. So that raises the question: should there be a single standard graph-relative public link contract?

Since a link contract is an entity, this means if you apply the test, "Will the entity subgraph be the same in all XDI graphs?", the answer must be "Yes". (Another way to put this test is, "Can this entity subgraph be merged with any other XDI graph without conflicts?".)

And I think that would be true for a standard graph-relative public link contract—which we can call the "common public link contract" since it's common to all XDI graphs that use it. That's because the only statement in that link contract would be:

$public$do/$get/$public

And this would be the same statement in any XDI graph that supports "public discovery".

On Thu, Dec 19, 2013 at 8:11 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

But still, in order to do a $get on

$public/$is()/{}

For this message to succeed you would also need to reference the public link contract, right?

Markus

On Thu, Dec 19, 2013 at 10:11 AM, Drummond Reed <drummond.reed@xdi.org> wrote:

In the last TC call Animesh pointed out that, now that public link contracts are going to be authority-relative, it is more difficult for an "XDI graph crawler" to index public XDI data.

While doing the minutes of the meeting, a simple solution occurred to me for how authority-relative public link contracts could become easily discoverable by "XDI crawlers".

All it requires is for an XDI authority who wants his/her/its public XDI data at an XDI endpoint to be "crawled" to add a statement to the graph in the form of:

$public/$is()/<--authority-id-->

where <--authority-id--> is the cloud number of the XDI authority.

All the crawler code would need to do is send an XDI $get message to the XDI endpoint for

$public/$is()/{}

Based on the response, the crawler could then request the public link contract for every XDI authority discovered in the first query.

Note that the $public/$is()/<--authority-id--> statement is graph-relative, not authority-relative, however this is fine because it meets the test of all graph-relative entity statements, i.e., it will be the same in all graphs, and you can merge any two XDI graphs without a conflict between graph-relative entity statements. For example, the statement

$public/$is()/[=]!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001

which states that [=]!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001 has a subcontext $public, is the same statement in all XDI graphs no matter what XDI endpoint it appears in.

=Drummond

xdi message