VOList: initial proposal

Deconstruct a table and you get a list of objects, one object per table row, where the objects have near-identical structure. The object-structure only varies to the extent that the table allows nulls in its columns.

The true table is an advantage if:

  • your tools (including DBMS) are designed for tabular data;
  • you want a trivial way of displaying the data to a human.

It's a disadvantage if:

  • your tools (including XML schemata) are designed for hierarchical data;
  • you need to express relationships between the columns.

In the latter case, it's more effective to simply list the objects.

The balance of advantage for the VObs is currently tipping from tables to lists of objects. VOList is proposed as a generic data-container, a sibling or cousin of VOTable, that presents lists of objects in a controlled form.

This is the data model for VOList.

(UML diagram of top of data model here...)

The document element is VOList and it contains a a hierarchy of resources. This idea is taken from VOtable where it seems to be useful. In contrast to VOTable 1.0, each element in this hierarchy can have a ContextualMetadata structure; the form of this is TBD, but one can imagine it containing curation and provenance metadata inter alia. All these parts are controlled by a W3C XML schema for VOlist as a whole.

The payload data are all contained in AnnotatedList.

(UML diagram for AnnotatedList here...)

(document is incomplete; more to follow...)




Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2004-05-26 - GuyRixon
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback