Discussion Page for Datalink UpdateHere are the new terms proposed to enrich the datalink. They should be discussed within the DAL WG. Feel free to suggest your terms here and provide feedback after usage , as data providers and client users. Here below is a template for suggesting new terms . you can copy this part and add your new requirement for terms .
| |||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||
> > | All links in DataLink that are not #this are implicitly "associated". The proposed structure here seems to be drifting away from vocabulary into something else. Finally, the idea seems to sanction using terms from the ObsCore standard but not very explicitly or in any machine-readable way (that could be partially improved by defining an ObsCore/dataproduct_type vocabulary). There is a lot here that needs discussion. -- PatrickDowler - 2019-05-08 | ||||||||||||||||||||||||
| |||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||
< < | I think this would be nice and useful to link one (or several) bibliografic reference(s) to the data. | ||||||||||||||||||||||||
> > | I think this would be nice and useful to link one (or several) bibliografic reference(s) to the data. | ||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||
> > | In CAOM we have a way to flag artifacts that become links in DataLink and we use "info" for this kind of thing. There is a fair bit of commonality between DataLink and the CAOM vocabulary (historical reasons) and I'd be happy to see them come closer together if possible. See http://www.opencadc.org/caom2/ProductType/ -- PatrickDowler - 2019-05-08 | ||||||||||||||||||||||||
| |||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||
> > | This seems useful and I could easily use this in the CADC DataLink service. -- PatrickDowler - 2019-05-08 | ||||||||||||||||||||||||
| |||||||||||||||||||||||||
Changed: | |||||||||||||||||||||||||
< < | Discussion paragraph : | ||||||||||||||||||||||||
> > | Discussion paragraph : | ||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||
> > | Replacing the semantics of the link that was to be generated by "fault" duplicates the fact that an error was already signalled by the presence of an error_message (instead of an access_url or service_def). There are numerous scenarios where the result would be ambiguous and hard for clients to use. For example, if the client wants to download data files "this" and there is a link marked "fault" the client cannot tell if they care about that failure. It could be a failure to find a preview or a service and have nothing to do with the data files. So, DataLink-1.0 design already covers the signalling of failure to create a link and this will break things. -- PatrickDowler - 2019-05-08 | ||||||||||||||||||||||||
| |||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||
> > | Agree that this sounds like #derivation. -- PatrickDowler - 2019-05-08 | ||||||||||||||||||||||||
| |||||||||||||||||||||||||
Added: | |||||||||||||||||||||||||
> > | This is something I have also run into but never solved because it is really a relation between a link and another link and not the link to the "identified thing" (with the ID). For example, say you have a DataLink output for one ID with two #this links and a #preview link and then you add a #alt link. Is it an alternative to the preview? One of the #this links? Both of the #this links? The possibly different content_type values might help or might not and I agree they don't say enough on their own (e.g. two #preview with different content_type are not obviously alternatives). So, I like this idea and there are use cases but it is too complex for #alt by itself. -- PatrickDowler - 2019-05-08 | ||||||||||||||||||||||||
<--
|