utype questions

[Douglas Tody]

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