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<[email protected]> > > To: Chris Holmes<[email protected]> > > CC: Ben<[email protected]> > > > > > > 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<[email protected] > > <mailto:[email protected]>> 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
