librelist archives

Re: [geonode] geonoding other data

From:

Sebastian Benthall

Date:

2010-05-25 @ 18:46

Thanks for getting in touch, Ben.

Some issues I would like to discuss:
> Naming Conventions: Some social sites like Facebook and Ning use terms
> like 'friend' and 'Groups', while on GeoNode wireframe they are showing
> 'Follow', and 'Following'. We prefer not to be too Facebooky, has anyone
> considered alternatives to these terms?
>

I think the difference in the designs here reflects a substantive difference
in proposed functionality.  In Facebook, "friendship" is a directionless
relation, whereas one user "follows" another user, adding the second users'
feed to their watch list, without reciprocation.

In the GeoNode wireframes there is a notion of a Group as well, because we
anticipate the need for organizations to want to have a presence on the
system, especially so that they can officially endorse certain content.


> Another naming convention issue we are trying to sort out is the
> ownership/authorship of data. The idea is that our tool will provide
> data, while users can import or create their own data. We would suppose
> that all this data could be labeled with the appropriate Author. Then
> someone could copy and edit some data, now does the author remain the
> same? Do we then allow the user to add a ownership field to the
> metadata? There would then be an Author, and an Owner, this might be an
> odd approach.
>

Our plans for this sort of thing are very open to criticism at this point,
but our current plan is to provide a fairly flexible permission system on
content uploaded by users, as illustrated in the lower right of this
wireframe:

http://geonode.org/wp-content/uploads/2010/03/GeoNode_20100517k.png

For the spatial data uploaded to GeoNode, our plan is to provide metadata in
line with the ISO19139 standard.  So, by that logic, the "Author" -- or, in
ISO-speak, the Responsible Party (there are two, actually, one for the data
and one for the metadata...) -- will be specified in the metadata.

I don't think we know the answer yet to a question like "How should the
metadata be automatically adjusted as users change permissions on spatial
data?"  Really good question though.


> Groups/discussion threads: our users are going to be able to follow
> discussion threads from various groups within our social network
> community. Would there be a way to allow the user to follow discussion
> threads from other sources, like the Understanding Risk community via
> Rss feed on their 'my page dashboard'?
>

I don't see why not.  We haven't thought much about this because we've been
focusing on the geospatial components for now, but a generic
feed-aggregating tool is definitely something that it's possible to build
into a Django site.

This is fairly custom functionality though.  It's probably something we
would want to develop as a plugin, especially because it duplicates
functionality that can be easily found elsewhere.  (Like Google Reader, for
example)


> On 5/15/10 1:03 AM, Chris Holmes wrote:
> > Hey all, we've started a discussion off list, but wanted to bring it on
> > to get others thoughts.
> >
> > Ben's working on seeing how a GeoNode could help the Global Earthquake
> > Model.  One thing they are interested in is having two additional types
> > of data that a 'user' would also have - curves and tables.
> >
> > Ben, could you tell us a bit more about how you anticipate using those?
> >    And explain what they are a bit more?  They also want 'maps', but
> > those are a concept GeoNode already has.
> >
> > The question is how GeoNode might handle other types of data.  Pieces
> > that are maybe created through use, or that users upload.  Presumably
> > you'd want others to be able to rate/tag/comment, and you'd also want to
> > let the owner manage the metadata about them?  And if they're generated
> > or associated with other parts of the GeoNode that relationship would be
> > nice to have, just like how maps use data and styles.
> >
> > -------- Original Message --------
> > Subject:      Re: GEM 2010 out-reach meeting in D.C.
> > Date:         Thu, 13 May 2010 11:38:23 -0400
> > From:         Sebastian Benthall<seb@opengeo.org>
> > To:   Chris Holmes<cholmes@opengeo.org>
> > CC:   Ben<ben.wyss@globalquakemodel.org>
> >
> >
> > My gut says that it would be best to separate out the different kinds of
> > data, especially since the spatial data has all sorts of specialized
> > and/or prescribed needs for its storage, retrieval, use, etc.  But it's
> > hard to say without more information about how you want to be using
> > charts and tables.
> >
> > For our current architecture, anything that isn't strictly geospatial
> > data is being handled by the database that the Django web-app uses.
> >
> > On Thu, May 13, 2010 at 10:54 AM, Chris Holmes<cholmes@opengeo.org
> > <mailto:cholmes@opengeo.org>>  wrote:
> >
> >       I think we basically would just let the Django backend handle it.
> >         See for example http://geonode.capra.opengeo.org/files/  This is
> >       .AME files, that we don't do anything special with, but you can
> >       browse, download and also get a bit more metadata info about, see
> >       http://geonode.capra.opengeo.org/files/2  You can manage its
> >       metadata, and upload new ones.  But our system does nothing special
> >       with it.  I believe we just treat it as a file, and django sticks
> it
> >       somewhere and knows about its metadata.  And I believe search
> should
> >       then be possible on that metadata.
> >
> >       Obviously this could be hooked up to other workflows, having the
> >       curves generated from a process, like a map.  Depending on the
> >       interactions needed we'd build up the functionality required.  But
> >       it's best if you're flexible on the file backend, so Django can
> just
> >       do its thing, instead of making an architecture decision about
> where
> >       to dump the features.
> >
> >       C
> >
> >       On 5/13/10 9:41 AM, Ben wrote:
> >
> >
> >           Hi Chris, We have been thinking about how best to structure the
> >           data.
> >           Our users will create maps, curves, and tables. We are thinking
> of
> >           dumping all these features into a single directory. Then we
> >           would have
> >           to create a fairly strong search index based on metadata to
> >           allow the
> >           users to search and retrieve data. Then the user would need to
> >           interact
> >           differently with the three kinds of features. What are your
> >           thoughts,
> >           how did you imagining to organize data in a GeoNode?
> >           Thanks,
> >           Ben
> >
> >
> >
> >
> >
> >
>
>


-- 
Sebastian Benthall
OpenGeo - http://opengeo.org