[ckan4rdm] Short introduction of project EDaWaX

[Ross Jones]

Hi Andrew,

Yes, that's exactly what I meant, I should have been clearer really.  Your client library can assume a basic working schema, but it might be extended by various plugins and as a client library you'll have no idea what that schema is, although a serialisation of the metadata format itself may be useful.

Ross


On 23 Apr 2013, at 11:01, Andrew Martin wrote:

> Ross,
> 	Is this what you meant when you mentioned recently a dynamic schema? This would have interesting consequences on the clients I'm trying to create....
> 
> Andrew
> 
> p.s. A little introduction for the RDM list...
> 
> I'm a developer (amongst other things) on the JISC funded "Iridium" project (http://www.jisc.ac.uk/whatwedo/programmes/di_researchmanagement/managingresearchdata/infrastructure/iridium.aspx) at Newcastle University, I have worked with quite a wide selection of systems over the past 10-11 years specialising in integrations and web services (including the first ever blackboard webservice... predating the official webservices)
> 
> -----Original Message-----
> From: ckan4rdm-bounces at lists.okfn.org [mailto:ckan4rdm-bounces at lists.okfn.org] On Behalf Of Ross Jones
> Sent: 23 April 2013 10:50
> To: CKAN for Research Data Management
> Subject: Re: [ckan4rdm] Short introduction of project EDaWaX
> 
> Hi Hendrik,
> 
> Hope you don't mind me joining in, I'm one of the developers on data.gov.uk and used to work on the CKAN team, and I thought it might be useful for me to contribute some details about CKAN.
> 
> On 23 Apr 2013, at 10:39, Hendrik Bunke wrote:
> 
>> Partly, yes. But there are other issues. One of the most
>> important for us is that CKAN lacks proper metadata schemes. In
>> our scenario CKAN will mainly be the discovery (or cataloguing)
>> tool. But to do so sufficiently we need more fields for metadata.
>> In addition, these fields should be based on a standardised
>> schema, like Datacite, da|ra or even DDI. That's what we will try
>> to do with our extension which I've described in step 3. CKAN.
> 
> The CKAN default metadata schema is deliberately simple as CKAN has support for customising the metadata schema and it is expected that people would use that to get exactly what they want. The schema we use for data.gov.uk is different than that used by the default CKAN install, and is different again from say, the EC Open Data Portal ( http://open-data.europa.eu/ ). Apologies if you already know this, it wasn't clear.
> 
> This is normally done via the CKAN extension mechanisms (IDatasetForm to be exact), and is even easier in CKAN 2 than it was in CKAN 1. It is also possible to 'type' datasets as well, each having a custom schema for the metadata if required.
> 
>> Depends on what you have in mind when speaking of 'curation'. The
>> basic idea is to enable editors to a) upload the data to CKAN,
>> and b) to manage the most basic metadata, both from within the
>> journal's CMS.  
> 
> Again, probably depends on exactly how everyone sees curation working, but curated datasets by trusted parties is something that will be appearing in data.gov.uk this year, and is likely to be released on github with our other extensions (https://github.com/datagovuk/).  It probably won't do exactly what is required, but I'm sure will make a good starting point.  As it is possible that it will be me doing the work, I'm open to suggestions on what would be useful to the RDM community as well.
> 
> Ross.
> _______________________________________________
> ckan4rdm mailing list
> ckan4rdm at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan4rdm
> 
> _______________________________________________
> ckan4rdm mailing list
> ckan4rdm at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan4rdm