Re: Hydra in relation to LDF/TPF

Hi Miel

Thank you for the haste response. Indeed I expected that our latest
activity would wake up old "daemons" :).

In general, I fully support what Tomasz wrote - we shouldn't put any
burdain on the core hydra spec that is TPF or LDF specific. Still, I
have no issues with maintaining possible extensions within Hydra CG.
The only thing that worries me is that the issues you probably refer
to were created 3 years ago without any specific outcome and my
feeling was those issues were somehow abandoned.

We can always reopen desired issues and proceed with discussions and
resolutions if needed so we can figure it out on how to enable hydra
for such cases (Tomasz's option 2, with which I agree). We'll still
ned help of people who understand TPF/LDF better.

Regards

Karol

śr., 9 sty 2019 o 10:21 Miel Vander Sande (UGent-imec)
<Miel.VanderSande@ugent.be> napisał(a):
>
> Hello Tomasz,
>
>
> The next telco is already planned for next Monday. Let us know if you will be able to join and we’ll make it a point to discuss.
>
>
> Perfect, we’ll discuss internally, but someone should be there at 8pm CET
>
>
> As for the relation between Hydra and TPD/LDF, personally I think that too close relation is not healthy. Being tech-agnostic, Hydra should only serve as basis for more specialized tools, defining common ground for various applications. Mixing TPF/LDF into the spec itself causes confusion and could eventually make Hydra too inflexible.
>
>
> I don’t think that was ever the intention. Yes, all three specs are hosted/maintained by the Hydra CG, however there is no dependency of the Hydra on LDF/TPF whatsoever (other way around obviously yes), but I get why a mixed github issue list creates that impression :)
>
> What I find important though regarding 'common ground for various applications’, is preventing that it becomes so generic that it no longer serves any purpose (there are many examples of specs). Keeping an implementation spec (LDF, TPF, or anything else) around (in the CG or somewhere closeby) can help Hydra stay grounded.
>
>
> That said, we’ll be more that happy to re-evaluate individual cases if we can reach one of two states:
>
> 1. To include proposed features into Hydra which benefit TPF/LDF as well as other APIs
> 2. To build extension points in Hydra which allow LDF/TPF-specific customisation, which otherwise will not leak into the generic spec
>
>
> Yes, completely agree, with a preference for 2!
>
> Cheers,
>
> Miel
>
>
> Best,
> Tom
>
> On 9 Jan 2019, at 09:36, Miel Vander Sande (UGent-imec) <Miel.VanderSande@UGent.be> wrote:
>
> Hi Karol, all,
>
> Our group has put the LDF and TPF specifications under the wings of Hydra some time ago, with the motivation that, at the time, LDF/TPF were the first applications or use cases of the Hydra vocabulary.
> This had the benefit that some (practical) issues in Hydra, e.g., the unclear semantics of hydra:search, got noticed and all specifications could push each other forward.
>
> When the activity in the CG declined, probably so has the relationship between both specifications and it seems the presence of LDF/TPF has become unclear. Now, with new leadership and momentum, it might be a good time to reassess the position of LDF/TPF in the Hydra CG. LDF issues becoming obsolete or ‘out-of-scope’ caught our attention and, while we definitely understand the reasons for separating scopes (I guess at least the github issues could be split), we better discuss first before we loose any important ties, documented issues or work.
>
> Unfortunately we missed the last telco, but I propose to put in on the agenda for next one to see how to best proceed. Would that be ok?
>
> Best regards,
>
> Miel Vander Sande
> Postdoctoral Researcher at IDLab, Ghent University, in collaboration with imec
>
> AA Tower | Technologiepark 19 9052 Ghent
> www.idlab.technology
> @Miel_vds
>
>
>
>
>
>

Received on Wednesday, 9 January 2019 10:30:33 UTC