Registry and Data Discovery
Paul Harrison
paul.harrison at manchester.ac.uk
Wed May 31 09:04:03 CEST 2023
Hi Markus,
> On 30 May 2023, at 17:40, Markus Demleitner <msdemlei at ari.uni-heidelberg.de> wrote:
>
>
>> ensure that the model does work better for data discovery. It is
>> clear that the 1.x registry data model is not sufficient to do good
>> data discovery, but I think that a better direction of travel to
>> expand the DataCollection part of the model rather than compress
>> everything into a Service.
>
> Oh, that's not what we're trying. It's more "everything can have
> (auxiliary) capabilities". We *could* have effected about the same
> thing expressing the auxiliary capabilities with relationships, but
> the price in terms of query complexity was so high that the slight
> blurring of the DM seemed a good deal. If I may quote the Zen of
> Python:
>
> $ python -c "import this" | egrep "break|practicality"
> Special cases aren't special enough to break the rules.
> Although practicality beats purity.
>
>
I too am all for practicality and the reason that I did not pursue this too much further in the original email, was that
I am going to go away and build some stuff (it is now 50% of my day job to do VO related things) before trying to suggest any alternative solutions. It might have been the rules around registry authority ownership that meant that no-one ever felt empowered to register SDSS as a DataCollection for instance - perhaps there should be a special authority for such “global” entries and that they be community maintained in some fashion, or it might be that data discovery is really better done by a different service.
Cheers,
Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2893 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20230531/f60f65c9/attachment-0001.p7s>
More information about the registry
mailing list