UType proposals

[Linde, A.E.]

I've NOT been following this thread, so please ignore if it has been dealt with, but re:

<<
The documentation can be organised so that a Utype string like :
obs:Curation.PublisherId is interpreted on the fly :
a) resolve the name space  obs --> http://ivoa.net/DM/Observationv0.9/
b) build up a link to the proper documentation page
http://ivoa.net/DM/Observationv0.9/Documentation/Curation.html
c) open it and highlight the
http://ivoa.net/DM/Observationv0.9/Documentation/Curation.html
#Curation.PublisherId section within this page.
>>

Wouldn't the namespace for 'obs:' need to be 'http://ivoa.net/DM/Observationv0.9/Documentation/Curation.html#' or do you mean that there is some sort of code at 'http://ivoa.net/DM/Observationv0.9/' which redirects to the full address?

T.

--
Tony Linde
Project Manager
Department of Physics & Astronomy
University of Leicester


________________________________
From: Mireille Louys <louys at newb6.u-strasbg.fr>
Reply-To: Mireille Louys <louys at newb6.u-strasbg.fr>
Date: Fri, 3 Jul 2009 17:31:27 +0100
Cc: SemIVOA <semantics at ivoa.net>, Dm_Ivoa_List <dm at ivoa.net>, IVOA DAL <dal at ivoa.net>
Subject: Re: UType proposals

Dear all,

I have been following the various points on the Utype discussion thread
on the various lists.
I thank you for your various contributions and ideas , that offers other
aspects than the one discussed in the draft I circulated just when the
IVOA meeting started in Strasbourg.

I just want to remind you that we would like to agree on a simple Utype
representation from the data model point of view, well focused on
implementations at the application level as well as the protocol level.
Our first focus is to discover, access and manipulate data of various
archives.
This is why we need to stick on the object programming properties
underlying the data modeling effort and the Utype string definition.

Considering the corpus of Utypes within a specific data model, like
SimDB, Observation, Characterisation, Simple spectral Line , etc...
one touches other vocabulary considerations. These are outside the scope
of the data modeling group, at least for the moment.

What I find interesting in Norman's proposal is the possibility to
enhance the documentation aspect of data models, which is tricky to
manage properly.
I think we can have a compromise in the Utype string definition, so that
the uri mecanism would allow to define the name space and build up links
to proper documentation pages describing classes of the model and their
attributes in well defined structured document.

Remember that a Utype string is derived from a data model, its root name
always derives from a class name, identifying a concept in the model so
the critiscism that it is a simple string unaware of his context is not
valid.

The documentation can be organised so that a Utype string like :
obs:Curation.PublisherId is interpreted on the fly :
a) resolve the name space  obs --> http://ivoa.net/DM/Observationv0.9/
b) build up a link to the proper documentation page
http://ivoa.net/DM/Observationv0.9/Documentation/Curation.html
c) open it and highlight the
http://ivoa.net/DM/Observationv0.9/Documentation/Curation.html
#Curation.PublisherId section within this page.

This is not as sophisticated as an ontology , but it would certainly
help data providers and users to implement, and use models.

cheers, mireille




--
--------------------------------------------------------------

  Mireille LOUYS          mailto: Mireille.Louys at astro.u-strasbg.fr

L S I I T                       &     CDS,
Ecole Nationale Superieure            Observatoire de Strasbourg
de Physique de Strasbourg,            11, Rue de l'Universite
Boulevard Sébastien Brant, BP 10413   67000 STRASBOURG
67412 ILLKIRCH Cedex                  Tel: +33 3 90 24 24 34
---------------------------------------------------------------


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/semantics/attachments/20090704/f41b3aa9/attachment-0007.html>