utype questions

[Douglas Tody]

Hi Matthew -

Your usage of UTYPEs is actually pretty unusual; no one has yet
used them to identify query parameters.  While query-by-DM-UTYPE
would be possible, parameters generally have more complex semantics.
UTYPEs are instead simply used to identify the fields of a data model.
To understand the attributes of a data model, one needs to first
understand the full data model, that is, the object being described
by these attributes.  There are many contexts in which such a DM
could be used.

A simple example from classical astronomy is a FITS WCS.  In FITS this
is represented as a bunch of keyword-value pairs.  If we separate
the semantics (data model) from the representation then the UTYPEs
identify the data model attributes, adding a namespace and avoiding the
8 character and other limits of the FITS representation in the process.
We can serialize the same FITS WCS in many ways, but it is the same
object in all cases.  Class code which manipulates the WCS does not
care how it is serialized.

To understand an individual attribute of the WCS it really won't do
to merely look up a brief description of that individual parameter;
one really needs to understand the WCS object.  In any case when
one manipulates a WCS the primary thing is not to look up help text,
but to be able to easily access and manipulate the WCS attributes.
Neither does the user care much about individual WCS attributes,
rather they want to know in general terms what kind of WCS it is.

In other words it is a complex object.  If you are focusing on
individual attributes and not the object, you are missing the point.

 	- Doug


On Mon, 29 Jun 2009, Matthew Graham wrote:

> Hi Doug,
>
> My understanding of UTYPEs is as follows: they identify a concept from a data 
> model and would be used in situations like a HTTP GET request to identify the 
> thing that a key is referring to, e.g.:
>
> http://some. service?seap:pos.ra=123&seap:pos.dec=12&seap.pos.size=0.5
>
> Where "seap:pos.ra" identifies an RA position in the SEAP data model (hence 
> the 'seap' namespace), "seap:pos.dec" identifies a Dec position and 
> 'seap:pos.size' identifies a size. Now I should be able to look up the 
> meanings of these UTYPEs (although really they are URNs) somewhere to see 
> what they actually refer to.
>
> If this is the case, what is wrong with having URIs instead of URNs? That way 
> I do not need to try and figure out where the data model description is to 
> see what the key means. When I am processing TBs/PBs of data for scientific 
> analysis and computation, I am certainly not going to rely on just string 
> matching but will want to dereference the key to make sure that it is 
> referring to exactly what it needs to be.
>
> What am I missing here if this is not the case?
>
> 	Cheers,
>
> 	Matthew
>
>
>
> On Jun 29, 2009, at 5:07 PM, 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
>>> 
>