Surely these are not exclusive or even complementary.
Hyper spatial and semantic are the user views - we do not have a User Requirements Doc but if we did it should be in this form.
I fail to see how you list ConeSearch etc. as Hyper Spatial and ADQL as strictly relational. Any cone Search may be expressed as ADQL (even SIAP) - but ADQL at least ADQL/x is a lower level - a machine thing.
As you sate under Hyper Spatial the Relational View is a way to implement this. Here we do indeed get a little into architecture - the design of the system will be influenced by the model we choose. The mapping and utilization of Relational and OO models remains unresolved. There are places for both. I suppose some discussion of this may be useful - we have to deal with both since we are about federating rather than building from scratch to a certain degree.
I don't think it is useful though to list these as mindsets - they are views of the same problem space. Different views are helpful at different junctures. Classically we would have the User View and the Software Design View and the Implementation View. These often would map onto Hyper Spatial/Semantic , OO, and some mix of OO and Relational.
On Sun, May 30, 2004 at 10:05:34AM -0700, Roy Williams wrote:
> Please find below some Sunday morning musing on the different mindsets in the VO
> (I count four). Are there more or less? Does this analysis get us any closer to
> our goals? Does this text have a place in the architecture document?
> Roy
> --------
> California Institute of Technology
> roy-at-caltech.edu
> 626 395 3670
>
> --------------------------------------------------------------------------
> Epistemology of the Virtual Observatory
>
> Here we consider ways of thinking of ourVO clients. They might come to the VO
> with one or more of the following mindsets, as described below: Hyper-spatial,
> Relational Table, Object Data Model, or Semantic.
>
> -- Hyper Spatial
> This mindset has been explored at NOAO[1], CfA[2], and in the Japanese VO [3].
> In this approach, data is connected to a photon or other particle that brings
> astronomical information through it's detection. Conceptually then, data is
> "located" within a multi-dimensional space ("hyperspace") that defines the state
> of a detected photon. This includes the direction of travel of the photon (sky
> position), as well as its wavelength, arrival time, and polarization.
> Collections of photons can also be associated with a spectrum, redshift,
> distance, physics, etc.
>
> In the VO, the Cone Search *request* is in this class -- although the Cone
> Search *response* is a table (next section). The Simple Image Access request is
> also in this "spatial" class, as is the Spectral Access.
>
> Much of the visualization work uses the sky coordinates (RA, Dec) as its first
> guiding principle -- Aladin, Oasis, Image Cutout and Virtual Sky. There is work
> in the VO to build a schema that accurately defines spatial regions, leading to
> the VORegion standard that allows precise definitions of subsets of the
> (hyper)sky.
>
> -- Relational Tables
> The relational mindset considers astronomical data through the Table model -- a
> RowSchema followed by lots of Rows. In general, images or other spatial data (eg
> spectrum) is examined by pattern-matching software, that generates pattern
> matches, each of which becomes a row in a table. Alternatively, individual
> photons can be measured, and each becomes a row in the table. (event list).
>
> Queries are built as boolean combinations of predicates on the attribute names
> of the columns. The VO has built ADQL, a standard variant of SQL, and added
> extra features.
>
> In the table model, the Row object is thought to be a sequence of primitive
> types (integer, float etc), and the RowSchema defines this sequence. The
> RowSchema is limited in complexity: by keeping the table cells very simple in
> structure (i.e. just fixed-format primitives), we maximize the thrust and
> utility of general tools.
>
> VOTable is built on the Relational model. In VOTable, cells can be
> variable-length, multidimensional arrays of primitives. The OpenSkyQuery
> protocols are also Relational in their mindset -- what is the set of tables,
> what are their attributes, here is an SQL query.
>
> -- Object Data Model
> This is the classical way of "data modelling". Objects are defined in terms of
> the methods they have and the interfaces they implement. Objects can inherit
> methods and interfaces from other objects. Queries are built hierarchically, for
> example finding where the resource/curation/title contains a given word. The
> data model approach also supplies immediate data structures for programming.
>
> XML schema has been a rich language for the VO in communicating the object
> mindset. Software is available to take an object collection that is expressed
> in XML Schema, and convert it to client-server code so that the logic of the
> object can be implemented (stub code), and so the object can be remoted (SOAP).
>
> The VO Registry is built with an object model, so that every resource in the
> registry has a basic view (eg Dublin Core), and then can be specialized to more
> complex metadata descriptions (eg where in the sky).
>
> -- Semantic
> The semantic mindset relies on both natural language and reasoning to encode and
> discover knowledge. The VO registries, like every other information collection,
> can use natural language in the simple sense of searching for words and phrases:
> "find me services whose description has 'quasar' in it".
>
> The VO has been working to promote the "Unified Content Descriptor" (UCD)
> project, which has built a formal language of semantic types for astronomical
> data. For example "phys.mass" means that the quantity is a physical mass. There
> are services to explain or compare UCDs. UCDs can fulfill the role of names in
> a query, or act as an intermediate lingua franca when diverse relational
> databases are federated. In this sense, UCD acts as a generic data model for all
> of astronomy.
>
>
> 1. http://iraf.noao.edu/projects/vo/dal/datamodel.html
> 2. sorry, I can't find this. It was a proposal from CfA to extend cone search
> into wavelength, time, etc.
> 3. http://jvo.nao.ac.jp/Documents/VOQL-yshirasa-2004-05-v0-5.pdf
Received on 2004-06-07Z14:38:27