[kforge-dev] ckan, how it might happen

[Rufus Pollock]

Jo Walsh wrote:
[snip]
> nodel, the simple app toolkit, you feed an RDF schema and it generates
> RESTful handlers for html and xml interfaces, sortof rails-style.
> I am happiest using it for pure machine interfaces, but you can bung
> (currently cheetah) interfaces and have html views; the nodel package
> supplies some basic user management and permissions functions, though
> perhaps not fully fleshed out to what CKAN might need; i've made quite
> wiki-nature, open interfaces to it.

This sounds really good. I think we can keep in mind a useful 
distinction within the model (as opposed to model vs. view) which I have 
introduced on the wiki page for use cases -- derived directly from your 
diagram :):

   http://www.okfn.org/kforge/wiki/OpenRegistry/UseCases

This the distinction between model stuff that is there to run the webapp 
and model stuff that is there to actually model the domain we are 
interested in. Thus: Permissioning stuff and user managment would go in 
the webapp side of things and all the metadata stuff would be 'pure' 
model. I think for the time being we can really focus on the 'pure' 
model and pretty much forget about the 'webapp' part -- that can come 
later or even be provided by another framework.

> Saul is actually threatening to make a moinmoin-style set of templates
> for it. And that does seem a little crazy, and it would be nice to
> have a very extensible metadata store which can be a plugin to a wiki
> working over HTTP, as i think Rufus was suggesting. I've done this
> with a previous, perl-based, rdf/xml restful http interface and a
> plugin for the CGI::Wiki module, it worked out pretty well. You can
> match for wiki page names, for example, on name-type properties of
> objects in the RDF data store. Using that with a vocabulary like DOAP,
> Description Of A Project ( http://usefulinc.com/doap ) designed for
> software projects but very applicable to data / information projects
> in general, augmented with Dublin Core. 

Having thought about this a bit this is really all about the view/model 
distinction. For example if we plugged into moinmoin we wouldn't want to 
actually store the metadata in the wiki itself, at most we would want to 
use the wiki for commenting and displaying the metadata. Thus the wiki 
is just a view (though a quite powerful one with some webapp stuff 
integrated). If it is just a view we can (and should) decouple the wiki 
rendering from the underlying model (particularly as we may one day not 
want other views or access methods to the model). Thus I think that we 
can again focus on getting the underlying metadata model done with a 
good (command) interface and then plug that in to the view. At least for 
a spike solution this could be done in quite a hacky manner. I've been 
playing with moinmoin for a bit and particularly was interested in the 
Metadata plugin:

   http://theendmusic.org/programming/MetaDataPlugin

Though this stores data in moinmoin (however could be useful for 
rendering and also for mockups). More similar to what we want is the 
FFII's gauss system for patents:

   http://gauss.ffii.org/

Check out an actual patent view:

   http://gauss.ffii.org/PatentView/EP747840 (cgi scripting!)

> I wonder if the project should be taking into account government
> metadata schemes and standards for kinds of public sector information,
> whether that is a priority now. I'm not really sure what other kinds

I think this would overcomplicate things at this stage. Let's follow 
KISS, and do the simplest possible metadata set possible. I mean it 
could just be dc:title, description of some kind, comments, tag, data 
source, license.

> of use cases people will have for different kinds of structure and sources
> of public sector data. In the world of geodata there is in theory
> encouraged use of ISO standards you have to pay to even look at, but i
> don't see them in the wild.

> Anyway, i'd like to throw together a simple 'spike solution' very
> soon without worrying too much about a spec, then have something to
> talk about, although i would appreciate any ongoing conversation on
> the subject, and the related one of how it might easily and usefully
> share data with kforge. The RDF rational for me is, "easy to get into, 
> easy to get out of, very comprehensible, well-known expressions for 
> a lot of this domain already, and i have a convenient toolkit". 

This sounds great. Let me know if there is anything you want me to do.

~rufus