utype questions (issue 2 - dereferencing)

[Norman Gray]

Greetings, all.

Here are some remarks specifically about the second of the three  
issues that are being discussed, that of the pragmatics of  
dereferencing URI-UTypes (supposing we decide that that would be a  
good idea).

What might come back when you dereference a URI?

Doug noted (http://www.ivoa.net/forum/semantics/0906/0923.htm):

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

The thing is that these aren't conflicting goals (and 'hear, hear' to  
Matthew, by the way).  A URI can return multiple formats, and if one  
of those is RDF, then it can describe just about anything you  
subsequently want to say about a particular element of a data model,  
addressed to a human or a machine.  For example:

<http://eurovotech.org/objects-structure#RadioQuietAGN>
     :prefLabel "Radio Quiet AGN".

or

<rdf:Description rdf:about="http://eurovotech.org/objects-structure#RadioQuietAGN 
">
   <skos:prefLabel>Radio Quiet AGN</skos:prefLabel>
</rdf:description>

At the same time, it is entirely compatible with...

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

You don't _have_ to make the URI dereferenceable.  If so, then it's a  
simple tag, which just happens to have colons and slashes in it.  If  
you then change your mind, you can make it dereferenceable.  If it's  
just a dead string, however, then you're stuck -- there's no  
possibility of future expansion without inventing _another_ mechanism.

In a world where astronomical data is going to increase in size and  
complexity, I don't think we can afford to think about only  
contemporary analysis requirements.




Later, there was a message from Doug, quoting Matthew and Rick (http://www.ivoa.net/forum/semantics/0906/0932.htm 
):

> Hence if the value of Target.Class is something like
>
>    http://eurovotech.org/objects-structure#RadioQuietAGN
>
> then this is the string which will be displayed to the user in
> many (probably most) cases.  This is not acceptable.

Indeed, that would be completely unreasonable, as would the very long  
UTypes mentioned in the Char'n draft.  Creating some 'short UTypes',  
as I've seen proposed, is not the answer, because they'd need yet  
_another_ TBD mechanism to link them to the ordinary UTypes.

> The way I would expect this to work is more like this:
>
>    o	The data model specifies the vocabulary to be used for the
> 	acceptable values of Target.Class.  Somewhere this vocabulary
> 	is defined, e.g., by a document such as
>
> 	  http://www.ivoa.net/internal/IVOA/IvoaSemantics/WD_2007-02-19.pdf
>
> 	or via some online service.  These data provider will use these
> 	tools to determine the appropriate target classification when the
> 	metadata is created.
>
>    o	Target.Class has a value such as "RadioQuietAGN" in our query
>    	response table.  When we use simple tools to view the query
> 	response this is what the user will see, e.g., in a table listing
> 	the objects found in some data query.
>
>    o	If more information on the object classification is desired
> 	a client application might consult the registry to find a
> 	service capable of doing useful things with the vocabulary
> 	in question.  There could well be several such vocabulary
> 	services available, hence we do not want to wire a string
> 	such as "http://eurovotech.org/objects-structure" into the
> 	metadata in our DBMS.
>
> We could then display more detailed information describing the given
> class of object, or do things such as identify related classes of
> objects, and possibly repeat the search using this information.
> In general there are any number of such things one might want to
> do, which is one reason that using a specific URL instead of the
> vocabulary-specific term is inadvisable.  In most cases just  
> displaying
> "RadioQuietAGN" is all that is needed.

That sounds very complicated, with more standardisation, and a future  
'vocabulary service'.  I think we can make it simpler:

   o  Target.Class (and the like) can be anything.  Obviously, if  
you're publishing data, it's a Very Good Idea to make this one of a  
standard set of terms.  This vocabulary or vocabularies (or ontology)  
is described in HTML/PDF plus an RDF file at <http://eurovotech.org/objects-structure.owl 
 > (or XML or whatever).  We currently have a prototype XML-RPC  
service to go from strings to vocabulary terms, but this step isn't  
hard.

   o  Target.Class has a value such as http://eurovotech.org/objects-structure.owl#RadioLoudAGN

   o  If you want more information on the object, for example its  
display label "Radio Loud AGN", you just retrieve and parse http://eurovotech.org/objects-structure.owl 
  (you probably don't do this at run-time, of course, but at build  
time, and bake the results into the application).  That's it -- done  
-- using only standard mechanisms, and with no services other than a  
web server.  If all else fails, you can just crop the UType after the  
'#' thus reverting to the situation you describe above.

[These points overlap with Rick's in http://www.ivoa.net/forum/semantics/0907/0933.htm 
]

In most cases, it'd be best to use a vocabulary/ontology which is an  
IVOA standard, and so distributed at a www.ivoa.net URL.  But in some  
more specialised cases, it might be necessary to use a subdiscipline- 
specific term, which would be at a different domain.

All the best,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
Dept Physics and Astronomy, University of Leicester, UK