Fwd: SKOS concepts in VOTable

Fri Jun 1 00:01:53 PDT 2012

(an exchange which accidentally didn't make the list)

Dear Norman et al.,

I still think life would be easier if one knew exactly what to expect up front - say,

	- "type" means the link is meaningfully semantic is some sense, but you have to figure it out for yourself.
	- "rdf" means, well, RDF/SKOS/...
	- "doc" means the link leads to documentation
	- ...

or even Norman's new favorite, "seealso", meaning the link is somehow related (which sounds a bit like "random" to me, but grab bags can be fun).

These and other tags would tell you exactly what to expect (and hence whether your software should even bother to try to follow the link).  On the other hand, if everything was trivial, we'd put a lot of students and software engineers out of a job.

I can only re-iterate, that I'll ultimately buy whatever Norman says will work - but it would be nice to know that it is indeed going to work.    Let's go for <LINK> and haggle a bit more about the details.

Rick

On 31 May 2012, at 22:57, Norman Gray wrote:

> On 2012 May 31, at 21:17, Frederic V. Hessman wrote:
> 
>> i'll buy this, but with this argument, you can, e.g., argue for the abolishment of mime types (or, for that matter, file extensions): after all, your clever programmer can always write a parser that can figure out if the bits coming off the stream correspond to something which she should be able to deal with - it's just a question of knowing a few (hundred) bit patterns and bit hints - easy, and by definition future-compatible with any functioning software.
> 
> But no -- all this is orthogonal to MIME types.  I carefully didn't say what you get back when you dereference, say, http://purl.org/astronomy/vocab/DataObjectTypes/Image.  My expectation, of course, is that it's RDF, but it could be anything, including HTML documentation of the concept, or some future IVOA document standard (preserve us from that!, but it's possible in principle).
> 
> The parsing would all be driven by MIME types: there's certainly no content-sniffing going on.
> 
> What you get back depends on what you ask for, and it would be wise to require providers of IVOA standards to provide both HTML and RDF.  In this case, if you ask for RDF, you get:
> 
> % curl -i -H accept:application/rdf+xml http://purl.org/astronomy/vocab/DataObjectTypes/Image
> HTTP/1.1 302 Moved Temporarily
> Date: Thu, 31 May 2012 20:37:35 GMT
> Server: 1060 NetKernel v3.3 - Powered by Jetty
> Location: http://votheory.obspm.fr/existenceService?uri=http://purl.org/astronomy/vocab/DataObjectTypes/Image
> Content-Type: text/html; charset=iso-8859-1
> X-Purl: 2.0; http://localhost:8080
> Expires: Thu, 01 Jan 1970 00:00:00 GMT
> Content-Length: 332
> 
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <HTML>
>   <HEAD>
>       <TITLE>302 Found</TITLE>
>   </HEAD>
>   <BODY>
>   <H1>Found</H1>
>        The resource requested is available <A HREF="http://votheory.obspm.fr/existenceService?uri=http://purl.org/astronomy/vocab/DataObjectTypes/Image">here</A>.<P>
>   </BODY>
> </HTML>
> % curl -H accept:application/rdf+xml 'http://votheory.obspm.fr/existenceService?uri=http://purl.org/astronomy/vocab/DataObjectTypes/Image'
> <?xml version="1.0" encoding="UTF-8"?>
> <rdf:RDF 
> 	xmlns:skos="http://www.w3.org/2004/02/skos/core#"
> 	xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
> 	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> 
>> 
> <skos:Concept rdf:about="http://purl.org/astronomy/vocab/DataObjectTypes/Image">
> 	<skos:prefLabel xml:lang="en">Image</skos:prefLabel>
> 	<skos:inScheme rdf:resource="http://purl.org/astronomy/vocab/DataObjectTypes/Scheme"/>
> 	<hasVersion xmlns="http://purl.org/dc/terms/" rdf:datatype="http://www.w3.org/2001/XMLSchema#int">2</hasVersion>
> 	<modified xmlns="http://purl.org/dc/terms/" rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-09-02T08:28:37Z</modified>
> 	<contributor xmlns="http://purl.org/dc/elements/1.1/">moreau</contributor>
> 	<date xmlns="http://purl.org/dc/elements/1.1/" rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2011-09-02T08:28:37Z</date>
> 	<skos:broader rdf:resource="http://purl.org/astronomy/vocab/DataObjectTypes/DataObjectType"/>
> 	<skos:broaderTransitive rdf:resource="http://purl.org/astronomy/vocab/DataObjectTypes/DataObjectType"/>
> 	<creator xmlns="http://purl.org/dc/elements/1.1/">moreau</creator>
> </skos:Concept>
> </rdf:RDF>
> %
> 
> At this point we know, if we didn't know it before, that .../Image is a SKOS Concept, so we can switch on that as assuredly as if we had had @content-role='skosconcept'.  And our application probably _would_ know this before, because if .../Image means anything to us at all, one of the things we know about it is that it's a SKOS Concept.
> 
> If you ask for RDF, and it's not available, then you can't find out about the concept on the fly.  But that's OK, because I imagine that in most cases, an application will just look up the string value of the URI in some internal table, and the solution reduces to the same functionality we have with UCDs.  Not great, but enough to build applications on.
> 
>> In fact, why bother to even have content-role attributes at all: simply throw the link at them and, if they're good, they'll be able to handle it.  Hey! - we're all good, of course, so no problem!   ;-)
> 
> No, I'm not saying that @content-role='type' is doing no work at all.  The (non-normative) text in appendix A.1 of the VOTable spec mentions 'query', 'hints' and 'doc' as possible roles -- those are indicating very different species of link relationships.  What content-role='type' is saying is that there is _some_ sort of 'is-a' relationship here, but being agnostic about the precise relationship, on the grounds that the precise details can be deduced from the type of the 'type': if it's a SKOS concept, then the VOTable column is in some way related to that concept; if it were a UCD, then the column would represent a number which could appear in a database column, and so on.
> 
> Given a free hand, I'd be a lot more precise about the relationships, through a slightly different mechanism.  But this is VOTable, so minimal pragmatic changes are the order of the day, while preserving as much flexibility as possible.