utype questions

[Matthew Graham]

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