Difference: VOListInitialProposal (1 vs. 2)

Revision 22004-05-26 - GuyRixon

 
META TOPICPARENT name="VODaX"

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.

Changed:
<
<
(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.

Changed:
<
<
(UML diagram for AnnotatedList here...)
>
>
 
Changed:
<
<
(document is incomplete; more to follow...)
>
>
An AnnotatedList may contain ContextualMetadata.
 
Added:
>
>
The AnnotatedList contains exactly one List. These two elements are defined by the XML schema for VOList as a whole. That schema says that the children of the list may be of any type. The List also contains an XML schema for the particular type of object in the list. This latter schema expresses the constraint that all elements in the list are of the same type. Typically, the XML schema for the rows is built from elements in the IVOA data-model. Ideally, the children of List are directly parts of the IVOA data-model.
 
Added:
>
>
The HowToCrumple and HowToFlatten elements are not worked out in detail. They are placeholders for some structural metadata saying how to map from VOlist to relational storage.
 
Added:
>
>
 


<--  
-->
Added:
>
>
META FILEATTACHMENT attr="" comment="UML diagram for top of VOList data model" date="1085587677" name="VOList-resources.gif" path="VOList-resources.gif" size="4590" user="GuyRixon" version="1.1"
META FILEATTACHMENT attr="" comment="UML diagram for internals of VOList data-model" date="1085587736" name="VOList-lists.gif" path="VOList-lists.gif" size="6121" user="GuyRixon" version="1.1"
 

Revision 12004-05-26 - GuyRixon

 
META TOPICPARENT name="VODaX"

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...)




<--  
-->
 
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