utype questions

[Douglas Tody]

That would probably work within the context of the ontology and its
tools.  What happens when the user inputs the string "quasar" or
"agn"?  That is, how do we map user input to this URI; can we defer
this translation?.  Later when we want to review the data model and
display the object classification to the user what do we do to get
a simple string for display purposes? (e.g. in a table of objects).
Is there any good reason to not defer the translation until the
ontology tool is used?  Also, why should this be referencing a specific
EuroVO implementation instead of something more generic?

 	- Doug


On Mon, 29 Jun 2009, Matthew Graham wrote:

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