open-civic-data.json

{
	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)
}

added dc metadata object instead of "start" and "end" properties

The properties were inspired by geojson's properties feature. I think that the geometry key should not contain any properties in the open civic data spec, however, as they can be combined later. Here are two simple objects, one with geometry and one without:

{
  "category": "bicycle_parking", 
  "properties": {
        "capacity" : "10", 
        "type" : "U-Rack",
        "mount" : "Surface"
  }, 
  "geometry": {
    "type": "point",
    "coordinates": [-71.073283, 42.417500]
  }
}

{
  "category": "legislation", 
  "properties": {
    "text" : "We the people..."
  }
}

For the bicycle rack, you can 'plug' it into a GeoJSON feature as follows:

{
    "type" : "FeatureCollection",
    "features" : [{ 
        "type" : "Feature", 
        "properties" : {  
            "capacity" : "10", 
            "type" : "U-Rack",
            "mount" : "Surface"
        }, 
        "geometry" : { 
            "type" : "Point", 
            "coordinates" : [ -71.073283, 42.417500 ] 
        }
    }]
}

When converting GeoJSON to OpenCivicData you just move object-wide properties to the root of the OCD object. If your geometry is a FeatureCollection and you have feature-specific information such as line segment colors then I suppose you would leave them in the GeoJSON properties.

I am thinking that maybe we don't have a 'properties' key but instead just put all of the properties in the root of the object. This is demonstrated here: https://gist.github.com/825359

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.

+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