utype questions

[Frederic V. Hessman]

>> No, a utype is a label for a member of a data structure, which  
>> sounds like data-structure vocabulary to me.  Isn't Norman's  
>> original comment that what utypes mean appears to depend upon who  
>> you ask?  That sounds like utypes are closed systems unless we find  
>> a standardized means of translating them into other forms of  
>> knowledge.  The whole point of the vocabulary effort was to define  
>> a common platform for systematising and translating such labels.
>
> There is no need to translate or infer anything from UTYPEs, on the
> contrary this is precisely what we are trying to avoid.  A major point
> of UTYPEs is to provide a simple, direct, and *unique* way to specify
> the field of a specific data model.  Otherwise we might have been able
> to use UCDs, but these do have some meaning in a more global sense, as
> separate entities, causing issues and ambiguities when used as UTYPEs.

Ah, but the whole point is that you can use whatever labels you want  
to, all you need to do it provide a translation to some other  
standardized vocabularies and - voila - the intercomparison becomes  
possible.  Then UTYPE <--> UCD <--> OWL <-->.....

>
> To get back to an actual vocabulary, consider our use case of
> Target.Class:
>
> On Mon, 29 Jun 2009, Matthew Graham wrote:
>> To refer to an AGN use "http://eurovotech.org/objects-structure.owl#AGN 
>> "
>>
>> This has subclasses:
>>
>> "http://eurovotech.org/objects-structure#LINER"
>> "http://eurovotech.org/objects-structure#RadioLoudAGN"
>> "http://eurovotech.org/objects-structure#RadioQuietAGN"
>
> This is exactly what we need; the only issue is how we use this
> facility.
>
> If we do a data query and get back a query response which we want to
> display to the user, it is a requirement that we be able to display
> the object classification as something like "AGN" or "RadioQuietAGN".
> Displaying a URL in this case is not acceptable, nor is displaying
> the content of the URL, unless the user asks for a more complete
> description.
>
> The query response of a data query is often displayed directly, or
> with simple tools.  Any number of such tools might manipulate and
> display such a query response - a generic table display tool is a
> typical example.  Hence if the value of Target.Class is something like
>
>    http://eurovotech.org/objects-structure#RadioQuietAGN
>
> then this is the string which will be displayed to the user in
> many (probably most) cases.  This is not acceptable.

... and totally unnecessary.   I'm no OWL expert, but doesn't it  
provide the "preferred label" usage of SKOS?  Then you access the user- 
friendly version automatically.

Or does this mean that you need to translation path UTYPE --> OWL -->  
SKOS --> human ?

>
> The way I would expect this to work is more like this:
>
>    o	The data model specifies the vocabulary to be used for the
> 	acceptable values of Target.Class.  Somewhere this vocabulary
> 	is defined, e.g., by a document such as
>
> 	  http://www.ivoa.net/internal/IVOA/IvoaSemantics/WD_2007-02-19.pdf
>
> 	or via some online service.  These data provider will use these
> 	tools to determine the appropriate target classification when the
> 	metadata is created.
>
>    o	Target.Class has a value such as "RadioQuietAGN" in our query
>    	response table.  When we use simple tools to view the query
> 	response this is what the user will see, e.g., in a table listing
> 	the objects found in some data query.
>
>    o	If more information on the object classification is desired
> 	a client application might consult the registry to find a
> 	service capable of doing useful things with the vocabulary
> 	in question.  There could well be several such vocabulary
> 	services available, hence we do not want to wire a string
> 	such as "http://eurovotech.org/objects-structure" into the
> 	metadata in our DBMS.
>
> We could then display more detailed information describing the given
> class of object, or do things such as identify related classes of
> objects, and possibly repeat the search using this information.
> In general there are any number of such things one might want to
> do, which is one reason that using a specific URL instead of the
> vocabulary-specific term is inadvisable.  In most cases just  
> displaying
> "RadioQuietAGN" is all that is needed.

To base an entire trival user-interface on the existence of an  
ontology seems to be a bit risky when all you need (at first) is a  
vocabulary.

The trivial version of this task should be

	data -> utype -> vocabulary -> prefLabel -> human
	human request for related -> vocabulary -> list of broader terms ->  
prefLabels -> human

and, if needed, only then must you resort to

	human request for ontological connections -> list of broader therms - 
 > vocabulary -> ontology (-> vocabulary -> prefLabel) -> human

where the ontological aspects are used for deep and not trivial  
knowledge: you don't need an ontology to be able to connect "spiral  
galaxy" with "galaxy" if the vocabulary gives it to you for free.  On  
the other hand, you don't want to have to connect "molecular cloud"  
with "spiral galaxy" using a vocabulary.   As always, depends upon  
what you want.

> One comparision of vocabularies with UTYPEs that is valid is that
> both define a controlled namespace.  In the case of a vocabulary
> these namespaces can be very large.  In such a case I would think it
> is even more important to separate out the identity of the vocabulary
> from the use of instances such as AGN etc.

Exactly why it's good to have both specialized small vocabularies for  
speed and large reference vocabularies for compatibility/translation.

Rick