Use Namespaces to add terms from other Metadata Schemes

See also:

• #144 Namespace Discussion
• #103 Encapsulated Extensibility
• #87 Profiles

There is a wide variety of metadata schemes. They share a common core of terms, but also have many disjoint terms. To facilitate interoperability, it would be valuable to have a way to link the common terms across these schemes, and when foreign properties are added to data package metadata, to identify the source scheme.

A simple way to do this would be to create a translation table for common terms, and add a namespace feature to prefix foreign terms.

For reference to the terms in other schemes, here is a spreadsheet that links terms between Data Package, Metatab, POD, Dublin Core, CKAN, DCAT and Schema.Org.

A possible implementation of this feature would be to add a ‘namespace’ property:

{
   "namespaces":  {
    "pod" : "http://example.com/pod/namespace/url",
    "mt": "http://metatab.org"
  }
}

Then, foreign terms could be prefixed:

{
  "name": "my-unique-datapackage",
  "title": "My Unique Data Package",
  "pod:conformsTo": conformity-spec,
  "mt:keywords": { 'kw1', 'kw2' }
}

Processing With Namespaces

Tools that process datapackage metadata can use the name spaces to produce fully-qualified JSON, in which every property name is prefixed. Property names that are originally un-prefixed and are specified by a Data Package spec would be given a default datapackage prefix, for instance “dp:”. Terms that are linked could be re-mapped into the Data Package namespace. For instance the property name “mt:Title” could be remapped to “dp:Title”.

The namespaces feature should be optional. Tools that don’t recognize namespaces can use the defined data package properties without prefixes.

Impact

If the defined Data Package terms are never prefixed, then this feature could be implemented as a customization, and does not need to be incorporated into the spec. That is, the “namespaces” property can be added by end users as a custom property, and foreign terms can be prefixed, without changes to the core spec. So, this feature could be implemented by end users as a common practice, rather than a change to the spec.

Separability

Even if Data package do not incorporate namespaces, maintaining a term map like the one referenced above may be valuable to allow data package metadata to be transformed into other schemes.

Criticisms

Here is a discussion about why adding names spaces to JSON is a bad idea, or at least an accounting of all of the ways to do it wrong.

[eocarragain]

@rufuspollock @ericbusboom I know this has been discussed in before (see #110; #218), but isn’t json-ld a simple, widely adopted, unobtrusive, developer-friendly way of tackling his problem? Apologies if I’m missing something obvious!

[rufuspollock]

DUPLICATE. I’m closing this in favour of the newer issue that covers the same core ground #663.