Learning Registry Design Meeting 11/29/12 1PM PST

[Jim Klo]

Greetings,

Steve, Walt, any myself will be holding an open design meeting to discuss and finalize some proposed design modifications for implementing Update and Delete in a federated manner. We are hoping to get things settled so we can begin implementation immediately with completion hopefully before the end of year.

You are all welcome to join the call tomorrow, 11/29/12 at 1PM Pacific Standard Time (GMT-8).

Telcon info:

+1-800-605-5167

436796#

I will send out a summary of the proposed solution for discussion before the meeting.

- Jim Klo

Sent from my iPad

Sent from my iPad

[Jim Klo]

Here is a summary of the proposal that will be discussed.

https://docs.google.com/document/d/1xkktOHcpve7NDpf2_F6LRH94W1O0oEobOEuu5QwFaPo/edit

Thanks,

- Jim

Jim Klo

Senior Software Engineer

Center for Software Engineering

SRI International

t. @nsomnac

On Nov 28, 2012, at 10:57 PM, Jim Klo <jim...@sri.com>

 wrote:

[Steve Midgley]

One comment on this - it's worth clarifying/emphasizing that there are two kinds of IDs being discussed in Jim's document. 

There are LR envelope IDs, and there are resource_locator IDs. LR envelope IDs (aka doc_ID) is just a way to identify the envelope so we can refer to it again later. This lets us do replication, and it will in this new model let us do updates and deletes.

The resource_locator is used to store generally the URL of the resource being referenced. It is currently a string and we are proposing to make it "polymorphic" so it can be a string or an array of strings. If it is an array of strings, each string can be a distinct URL (or URN or any other identifier that is relevant). Each string in the array is considered "equivalent" to the other strings (probably not as rigorous as "owl:sameas" which is truly identical but more just semantically the same - one might be a flash video and one might be an youtube link but they hold the same content). There will clearly be variation in how this is implemented by different publishers, but that seems ok if everyone is working towards that goal of telling others about resources which are the same as others.

When creating a URN for doc_ID, as Jim proposes, this could imply selecting one of the URLs/strings in the resource_locator for part of the URN, over the other resource_locator URLs. This shouldn't be considered a "canonical" selection of that URL as the definitive one - just an arbitrary decision for representing uniqueness inside LR, which is the only purpose of doc_ID.

Anyway that's my two cents. Anyone who wants to join the call this afternoon (in about 10 minutes) should definitely feel welcome to do so. 

Best,

Steve