Datalink Feedback VI: Semantics

[François Bonnarel]

Wooouh !!!
     What a HUGE discussion for a little "meaning" field !
     After finishing reading let me say shortly what I think is needed.
     1 ) The field is needed right now. At least we have to distinguish 
previews from science data for Cube access   allready. Or do we want to 
restrict to science ? And  I hope we will need "metadata" rather soon 
when SIAV2 1.1 will provide the metadata (imageDM consistent) resource. 
(Imagine you hava an OBstap (ADQL based ) service and what a DataLink 
towards the full ImageDM metadata via a DataLink ...
     2 )  Is it "semantics" or "property" (à la rdf) or "concept" (à la 
skos). We want something to know what this link means so I still think 
that the wider "semantics" name for this field is enough. At the level 
of complexity we have (not heavy i Think) I do not see real differences 
between rdf/skos/and_even_UCD syndtaxes for the hierarchy we need.
     3 ) basic list. Should be in the DataLink spec.the basic list 
Should be extensible the way   Norman proposes it

"The DAL WG will from time to time reissue the Datalink core term list, in consultation with the community.  No terms will be removed from the list."

     4 ) this basic list is the entry point to a hierarchchal system of terms described elsewhere. We may avoid to choose the real system for now if it's too controversy.

Best regards
François

Le 25/04/2014 12:21, Norman Gray a écrit :
> Mark, Markus and all, hello.
>
> On 2014 Apr 25, at 10:03, Mark Taylor<m.b.taylor at bristol.ac.uk>  wrote:
>
>> On Fri, 25 Apr 2014, Markus Demleitner wrote:
>>
>>>> Q. Where do we specify the process for updating the vocabulary
>>>> itself? Is that something Semantics WG would have a general policy
>>>> about?
>>> Ah well.  The precedent we have is the UCD addition process, for
>>> which there's a standard of its own, and given that AFAIK nobody has
>>> even tried it I suspect that's not a particularly good precedent.
>> I'll note another relevant precedent.
>>
>> For SAMP the semantic content comes in the form of MTypes,
>> which are effectively RPC definitions (procedure name, arguments,
>> return values, and semantic intent).  The "core" MTypes
>> (mostly associated with hub and client lifecycle) are defined
>> in the SAMP standard.  All the others (the ones that make SAMP
>> useful, things like exchaning tables, images, sky positions)
>> are simply listed on a wiki page
>> (http://wiki.ivoa.net/twiki/bin/view/IVOA/SampMTypes).
>> There is no formally defined process for updating this list,
>> but informally people make suggestions on the mailing list,
>> and if nobody has objections, they just edit the page.
> Indeed.  The UCD precedent was one that occurred to me, and which I also wanted to shy away from, since it's turned out to be probably unusably heavyweight in practice.  The process has been invoked in the past, and there have been UCD updates, but it can't be called agile.
>
> I think the SAML MTypes model is much more appropriate for the development of a Datalink term list.  Markus, you proposed a process which involves the TCG: that element of oversight has attractions, but there's still a danger of over-formalising that.
>
> How about language like: "The DAL WG will from time to time reissue the Datalink core term list, in consultation with the community.  No terms will be removed from the list."
>
> All the best,
>
> Norman
>
>