Type examples

The following is the outcome of our VC on Nov 19. This page should reflect the up-to-date set of ideas and extended accordingly.

Note: If you want to contribute, comment, etc., please join the group ("subscribe to group" on the right hand side of the PIT WG entry page) or subscribe and post to our mailing list.

Initial working list of type examples:

• checksum
• relations in general (versioning, provenance, person IDs, aggregation, ...) - all properties that have another PID as their value
  • data object / metadata object distinction (dataONE) -> are these two enough? What about landing page? Maybe something like web service?
• timestamps: when was the PID record changed the last time vs. when was the data behind it changed the last time -> what about "First published"?
• formats -> should be free form :-)
• citation -> not sure what is meant here .. a bibtex entry?
• life cycle concerns
  • administrative: responsibility, licensing, contact point
  • fate of data / stability (tombstones); data in preparation; embargoed; dynamic data flag
• size of data
  • unit of size of data (MB, GB etc.)
• target of a resolving action

There are also some cross-cutting concerns having to do with type/property definition mechanics. These are not immediately relevant right now, but must be kept in mind, because they will come up at some point:

• we need a distinction between mandatory and optional properties, and this should be specified in a type definition <- also on the level of profiles: which types are optional?
• there must be a way to address multiply occurring properties of same name/key (like 'is-derivative-of'); this may impact the data structure for a type definition because some services may assume property names to be unique (set view) while others would like to provide a single name several times (is-derivative-of; list view).
• Tom: what data formats do we use for exchanging information back and forth between API and clients (XML, JSON, ...?)? -> Good argument for XML would be the fact that a content negotaion human beeing / machine is easy doable: just add an XSL definition to the XML output and the client can decide what to do: a browser will render the XML code with the help of the XSL script while a machine can ignore it
• we also need to define at some point types for property values (string, number, datetime, boolean, CV, ...)

Comments in red - Tom :-)