utype questions

[Matthew Graham]

Hi,

In that case, just use the Ontology of Astronomical Object Types that  
has been produced;

http://www.ivoa.net/internal/IVOA/IvoaSemantics/WD_2007-02-19.pdf

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"

which in turn have more subclasses.

	Cheers,

	Matthew

On Jun 29, 2009, at 5:23 PM, Douglas Tody wrote:

> To answer the more specific technical question of what to do about the
> specific use case I mentioned (object classification), what we would
> like to have from the semantics group in this case is a vocabulary or
> family of related vocabularies/dialects for classifying astronomical
> objects.  The data model in question would specify the particular
> vocabulary to be used for this specific object/DM attribute
> (Target.Class in this example).  What one would like is for the
> value string of Target.Class to be something simple like "quasar",
> possibly with some subclassification.  Given a value input by the
> user, one could then consult this vocabulary to find all observations
> (tagged by Target.Class) which match what the user asked for.
>
> We do not need to do anything to UTYPEs to provide this, but we do  
> need
> a usable vocabulary, plus implementations which could do the type of
> inference suggested above.
>
> 	- Doug
>
>
> On Mon, 29 Jun 2009, Douglas Tody wrote:
>
>> On Mon, 29 Jun 2009, Matthew Graham wrote:
>>
>>> So what is wrong with having a static URI that points a SKOS  
>>> resource that enumerates the different contents - this can be  
>>> editted as needed and as open-ended as you want but it also have a  
>>> fixed URI, is (de)referencable and allows for look-ups to see how  
>>> the same term is referenced in different dialects.
>>
>> So now we have folks that want a URI which points to an online help
>> page, and other folks that want a URI which points to a SKOS resource
>> for this (quite rare) type of data model attribute which could
>> benefit from use of semantic tools on the value string.  Naturally,
>> we would change the entire UTYPE mechanism to serve these various
>> conflicting goals.  What happens the next time we have a different
>> use case for a different type of attribute?  Perhaps we should do
>> also away with FITS keywords, UCDs etc. while we are at it?
>>
>> Lets keep UTYPEs as simple tags used to identify data model  
>> attributes
>> in actual scientific data analysis code, and use other mechanisms
>> for these more specialized, occasionally useful, but less important
>> capabilities.  The #1 thing here is to be able to use the data model
>> for good old fashioned scientific analysis and computation.
>>
>> 	- Doug
>>
>>
>>> On Jun 29, 2009, at 2:47 PM, Doug Tody wrote:
>>>> Hi Frederic -
>>>> Maybe I am not understanding your question, but semantic  
>>>> inference is
>>>> a completely different issue from UTYPE.  We are dealing with data
>>>> models here, not vocabularies.  We do not want to have to infer the
>>>> field of a data model.  We just need simple static labels, defined
>>>> within the context of a single (versioned!) model, to allow model
>>>> attributes to be manipulated in a representation-independent  
>>>> fashion.
>>>> Now if our data model contains an attribute (UTYPE) such as  
>>>> Target.Class
>>>> to specify the class of astronomical object observed, we do need
>>>> semantic inference to do useful things with the value of this  
>>>> attribute.
>>>> The UTYPE "Target.Class" is completely defined by the data model,
>>>> but the contents are an open-ended vocabulary with the problem of
>>>> multiple dialects and so on.
>>>>
>>>> 	- Doug
>>>> On Mon, 29 Jun 2009, Frederic Hessman wrote:
>>>>> Sorry to dig back into the utype question, but why isn't the use  
>>>>> of multiple, translatable vocabularies a la SKOS the ideal  
>>>>> (indeed only) solution?  Don't want user readability, don't want  
>>>>> to enforce a single usage, don't need an ontology, don't want to  
>>>>> restrict mixing and matching as long as I can match what's been  
>>>>> mixed, just need a good label.   Or am I being naive and/or  
>>>>> single-minded?
>>>>> Rick
>>
>