Lens Library or introducing Lens document repositories about lens HOT 5 CLOSED

This looks like a good move, if I'm understanding correctly.

http://elife-converter.herokuapp.com/documents and
http://cdn.elifesciences.org/documents/elife/documents.json
are the same file content.

the _id elements of each article are only expected to be unique within the context of eLife.

If this goes ahead, it would be handy to specify the default context / repository so we can just skip adding the elife/ portion of the URL on a bespoke installation of lens.

Specifying a JSON document by the url method could maybe put the data into an "anonymous" context.

Extra points if it could be configured with multiple contexts / repositories and was able to merge multiple document indexes into the same lens, as well as locate the individual article JSON files for each.

from lens.

The entities "organisims" "subjects" and "keywords" are very eLife
specific, so if we were to go down this route we should have the least
amount of information required as the base json node for the repository,
with the ability to add enhancements to the information that a repository
cover might display.

If we start to describe repositories and collections of articles we are
starting to enter into the library world where a lot - perhaps too much -
work has gone into trying to understand how to formalise and describe
things.

On Thu, Aug 8, 2013 at 8:14 PM, Michael Aufreiter
[email protected]:

I think it's time to introduce the concept of a content repository to
Lens. We're quite close already, since we have defined a simple index
format that just provides meta information about a set of articles along
with their urls.

See: http://elife-converter.herokuapp.com/documents

However currently, one would need to configure Lens to be able to access a
different content repository.

Lens.ENV = 'production';
// Can optionally be an array specifying a file extension (we need that for static deployment)
Lens.API_URL_PRODUCTION = ['http://cdn.elifesciences.org/documents/elife', '.js'];Lens.API_URL_DEV = 'http://elife-converter.herokuapp.com';

It would be nicer to do that at runtime like so:

http://lens.li/#elife/00654 - for accessing an eLife article

http://lens.li/#plos-one/0048868 - for accessing a plos one article.

(btw. the lens.li domain is free... .li like "literature" ;)

The first part of the url is an alias for the content repo, which is
identified by a URL. In order to allow lens to display any document on the
fly, one could also provide a url to a lens document.

E.g. if you wanted to display
http://plos-converter.herokuapp.com/documents/journal_pone_0047695

you'd just have to provide the URI-encoded url

http://lens.li/#http%3A%2F%2Fplos-converter.herokuapp.com%2Fdocuments%2Fjournal_pone_0047695

Let's consider making repositories a first-class citizen and introduce the
Lens Library interface. A Library conforms to the JSON serialization format
we have right now.

It has an index of article records. One record looks like this:

{
"_id": "00051",
"published_at": "2012-12-13",
"name": "Global divergence in critical income for adult and childhood survival: analyses of mortality using Michaelis–Menten",
"authors": [
"Hum",
"Jha",
"McGahan",
"Cheng"
],
"journal": "eLife",
"article-type": "Research Article",
"keywords": [
"enzyme kinetics",
"adult survival",
"child survival",
"income",
"HIV",
"smoking"
],
"organisms": [
"Human"
],
"subjects": [
"Human biology and medicine",
"Microbiology and infectious disease"
],
"url": "/documents/00051"
}

Thoughts?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/40
.

from lens.

Those properties would not be enforced by the library interface. It's totally up to the user which metadata they want to put in. I'd like to keep things simple at first, the main purpose of this discussion is making Lens aware of multiple collections (aka make publishing to Lens really easy, without running your own instance). The faceted browsing part is not that important atm. We can keep using it for eLife as it is...

from lens.

All sorted out. Closing.

from lens.

As a side note... agreeing with @IanMulvany in that we shouldn't enter the library world "yet".

from lens.