[humanities-dev] Other authors in Open Shakespeare

[iain emsley]

Might another approach be to have a central repository with the authors
as collections and have a UI that can be reused with rewriting to serve
the individual collections rather than go down the individual Textus
instances and use the Rest API in that way? 

I think it would be useful to think about whether we would want to keep
the corpus work that was started in Shakespeare and could be useful in
extending to Milton and so on. It could be tied into the Weaving History
bits that have been tied in at some point. 

Iain

On Tue, 2012-06-05 at 13:47 +0100, Tom Oinn wrote:
> On 5 June 2012 13:16, Sam Leon <sam.leon at okfn.org> wrote:
> > Hi Iain,
> >
> > Really interesting question. On the last Open Humanities call we were joined
> > by Sarah Moriarty who's very interested in setting up Open Joyce.
> >
> > Like Rufus, though, I feel it might be sensible to set up more generic
> > domain specific instances of the chosen platform like Open Philosophy or
> > Open Literature.
> 
> I think there are two questions here:
> 
> 1) What are the benefits of a domain or author (or subject, topic,
> colour of original binding...) site?
> 
> 2) What operations are inherently precluded given a split of this
> nature and how can we enable them?
> 
> As I see it the reasons to create specific sites include:
> 
> * Control and a sense of ownership over a topic or domain. We rely on
> communities to create and curate content in these sites, by narrowing
> the scope of a site and giving it a distinct identity we create a
> banner under which such a community can coalesce. The restricted scope
> provides focus and a clear purpose to the site and allows for formal
> or informal teams of optimal size (that is to say, relatively small
> and strongly internally connected).
> 
> * Branding and publicity, if we say 'openshakespeare' people have a
> pretty good idea of what to expect when they visit the site. They may
> not really understand the 'open' bit but they will have some notion of
> who's work they'll be seeing!
> 
> The inherent drawback of such an approach is that we're picking a
> single axis of differentiation but in reality literature can be
> divided in any number of ways (just take a look at your bookshelf or
> your local library). If we have open<AUTHOR> for all authors what do
> we do when someone wants to create a bibliography or similar of all
> works addressing <TOPIC>? Clearly there's no single 'right' way to
> split the content at a conceptual level.
> 
> This came up in a relatively concrete fashion at the Textus session
> hosted by Goldsmiths the other week - one suggestion was to have
> annotations which were typed tags to indicate passages in texts which
> addressed particular themes. If we had openJoyce, openMilton etc how
> would we satisfy a query for 'passages in books written within <DATE
> RANGE> annotated as referencing <THEME>'? Where would that interface
> live, and how would a user ask such a question across what would be
> several different sites?
> 
> Fortunately I think we have a sane way out of this particular bind -
> the Textus server presents a REST based API for query and text
> retrieval, if we were to ensure that this could federate cleanly (i.e.
> a query to one Textus instance could query other instances and
> aggregate the results) we could have multiple independent sites but
> retain the ability to search over multiple instances. As Textus is
> built to allow deep links (i.e. link into a particular paragraph or
> annotation within a text) the result pages for such searches could
> trivially link out to other sites in a fashion transparent to users.
> As an aside, this would be a powerful motivation to move to e.g.
> openID or similar, otherwise users would have to log in to each site,
> breaking the seamless effect we'd like to achieve, but it's not a
> killer as no login is required to read texts.
> 
> We'd need some kind of central registry of Textus instances to which
> queries could be federated but we probably want that anyway, and there
> would be technical issues to work out such as performance but I don't
> think there's any inherent problem with the approach I've just
> described. We'd want UI support to allow users to specify the sources
> they wanted to query as well, but other than that the federation
> should be pretty much transparent. The default could be to not
> federate, but we could make it easy for admins of a Textus instance to
> add the ability to distribute queries to other instances, the set of
> which would be configurable.
> 
> Tom
>