[kforge-dev] ckan, how it might happen
rufus.pollock at okfn.org
Fri Nov 11 09:43:38 UTC 2005
Jo Walsh wrote:
> 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
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
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:
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
> 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.
More information about the kforge-dev