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