hi @seanherron. ISO has defined a structure for constraints put on a resource. they may include access constraints and use constraints and also include domain codes for the type of restriction put on the resource (copyright, patent, trademark, license, etc) and the classification of the resource (unclassified, restricted, confidential, secret, topSecret). While the ISO documents (ISO 191xx series, see www.isotc211.org/Outreach/ISO_TC_211_Standards_Guide.pdf) aren't free they are used internationally and form the basis for US (FGDC) and Canadian profiles, European (INSPIRE) profiles, etc.

More info on the North American Profile of metadata may be found at the FGDC website: http://www.fgdc.gov/standards/projects/incits-l1-standards-projects/NAP-Metadata.

Would be great to hear your views on how those specs can support project open data's effort to come with a simple implementation of metadata for a variety of global resources.

Thanks for the links - I'm a fan of the idea of using FGDC metadata where appropriate and this may be one of those areas. Part of me likes the simplicity and ease of using "license", as it's a generally universal term the primary audience for much of this data (developers and members of the public who may not have much experience working with complex metadata schemes) can easily understand. That said, maybe using UseLimitation along with accessConstraints (for public/private/restricted) and LegalConstraints (for licensing) would be a good fit here?

I think this bridges #93, #90, and #92 as well, so tagging them to bring in to the conversation.

I think what @mhogeweg was getting at was the concept behind the attribute. Current documentation just indicates that it needs to be open, but it's not explicit. That's, I think, where there is some interesting tension here in the discussions between the standards wonks (or geeks or whatever) who have spent countless hours debating this, that, or the other code list and folks thinking more in the abstract about metadata.

The Project Open Data "Common Core Metadata Schema" seems to be trying to become an abstraction across many different metadata standards, profiles, and conventions. So, what's the abstract concept we're trying to convey with "license" and how standardized does it need to be made to be actionable? I think many of us are working on how we map various standards (FGDC CSDGM, ISO19115-x) to the "POD" schema. The decision we need to make is whether we can just shove in what values we have from either code lists or raw textual content or if we need to translate those into a code list expected by POD. An interesting option with some attributes like this would be to allow for annotation with something like the following construct that would also allow for informative references to be included where applicable:

"license" : {
    "name" : "CC BY-SA 3.0",
    "uri" : "http://creativecommons.org/licenses/by-sa/3.0/",
    "annotation" : "While the dataset produced by the government is strictly in the public domain, it is released under the CC BY-SA 3.0 license because certain constituent information was originally licensed as such."
}

Software developers could choose to ignore all the extra cruft they don't care about and just go straight to the "name" (or whatever value), but the further detail could enable better understanding.

@skybristol I like that syntax, but I wonder if the additional value of the plantext name and annotation is worth the additional effort to agencies (however, this could be easily automated, especially if it was built in to CKAN's exporter).

As I mentioned above, I'm all for using existing schemas and standards, but for many of the people within government who are posting this data, they are entirely new and giving massive schemas to them can be detrimental to our efforts since it raises the barrier of entry. I think the common core is designed to be a super basic schema meant for non-metadata experts that is easily parsable and understandable, yet could be fairly easily also migrated to other schemas. I think your proposal makes sense, but I'll leave it to others to also chime in since I'm by no means the most knowledgeable person here.

After doing some thinking about this and chatting with others off-line, I think the best course of action for this may be to keep as-is now for simplicity and potentially revisit this for a future version of the schema.