Re: [Myexperiment-discuss] New user data: how?

[Danius Michaelides]

On Tue, 17 Feb 2009, David R Newman wrote:

> My preference would be for the functional option.  This need not be just a 
> third party field but also visible through myExperiment so that a user can 
> expose extra information about themselves that is not currently categorised. 
> Providing such flexibility may allow for improved design the future.  E.g. we 
> might discover that a lot of people want to post a link to their blog or 
> something.
>
>
> --On Tuesday, February 17, 2009 12:39:36 +0000 "Linde, A.E." 
> <address@hidden> wrote:
>
> > This is a question I raised a while back but now need to sort out. There
> > is a piece of information I need to store against each User in their
> > Profile or Account details that will be used in the Spacebok variant of
> > myExperiment. But rather than just this single piece of information (as
> > it happens, the endpoint for that user???s annotations triplestore), I
> > think we need a solution for anyone extending myExperiment to store extra
> > information.
> >
> > I guess the solution needs to be either procedural or functional:
> >
> > Procedural: in that there is a way in which changes to the database
> > structure can be retained by the extended codebase without being
> > overwritten by future changes to the core codebase.
> >
> > Functional: such as a 3rd party field in each table where those creating
> > extensions can store data (eg in a text field which contains XML data
> > with something like <3rd Party><App1><app1 data.../></App1><App2...
> > /></3rd Party>).
> >
> > What do people think.


Your 'procedural' solution seems to be inline with RoR's facilities to
extend functionality via plugins.

As for the 3rd party field, that seems to add alot of overhead having to
parse out data all the time. Plus you'd have to make sure every extension
uses the 3rd party field the same way.

I think I'd prefer a solution that allows you to associate key value
pairs with items. This could either be directly on database entries,
or extended further by storing triples in a dedicated table, or just
use a full-blown triplestore (with the added benefit that you're 'app'
data could be more structured). Biocatalogues annotation system is
related/relevant here.

Danius