-
-
Save cspanring/825314 to your computer and use it in GitHub Desktop.
{ | |
category : "", // Required Single category from (http://opencivicdata.com/#categories-wg) | |
properties : {} // Required Common bin for domain specific properties from from (http://opencivicdata.com/#properties-wg) | |
meta : { // Optional: Simple Dublin Core Metadata Element Set | |
title : "", | |
creator : "", | |
subject : "", | |
description : "", | |
publisher : "", | |
contributor : "", | |
date : "", | |
type : "", | |
format : "", | |
identifier : "", | |
source : "", | |
language : "", | |
relation : "", | |
coverage : "", | |
rights : "" | |
} | |
geometry : {} // Optional Geojson location feature (http://geojson.org/geojson-spec.html) | |
} |
+1 for the meta property, as long as it is simply an optional list of DublinCore metadata. If something doesn't fit into the metadata list then it can have it's own OpenCivicData property. Building on DublinCore is a good idea though
So we should use an option metadata property that expects these properties http://www.dublincore.org/documents/dces/ ? I like the idea of building on dublicore, but I'm concerned that we encourage something that is too specific. For example, the dublincore does not support an entity with a time range.
The beauty of the dublin core is that it's a widely accepted simple metadata spec. I think in terms of interoperability it's good to build on top of it. It can be extended and tailored to your application, e.g. just add time-range to the list if that suits your data (the meta properties are the 15 simple elements). I also think optional is important, it shouldn't stop anybody from sharing data.
a time range is data, dublincore is for metadata
data should belong in properties, metadata should belong in meta
ok, I'm clearly too GIS biased... http://www.fgdc.gov/metadata/csdgm-new/09.html
Open Civic Data is about creating a common vocabulary around geospacial and temporal entities. To do this, we want to be as loose as possible with the structure. At the top level, we want only the properties that 1) imply geospaciality or temporality and 2) properties for creating a common description framework.
The meta property you are suggestion is on the right track for this, as it is a property bag allowing for many disparate properties to land in there. Most of the properties that you have in meta, however, seem like they belong in properties though. For example; title, creator, subject, description, etc. Data about the data is kosher for the "properties" property.
Meta seems like it might make sense down the road if we ever get into higher level data about our system. We might use meta to store data to support a pay model, for example.
We may find that there are some civic data attributes that are common across all civic data. Even if this is the case, I would think that we would still put them into the "properties" property as they do not relate to temporality, geometry or common interface.