Re: Hydra in relation to LDF/TPF

Hi Karol,

At least me or Ruben wil be there, maybe both :)

Best regards,

Miel Vander Sande
Postdoctoral Researcher at IDLab, Ghent University, in collaboration with imec

AA Tower | Technologiepark 19 9052 Ghent
www.idlab.technology<http://www.idlab.technology>
@Miel_vds




On 14 Jan 2019, at 12:00, Karol Szczepański <karol.szczepanski@gmail.com<mailto:karol.szczepanski@gmail.com>> wrote:

Dear all

Just a reminder, there will be a conf-call today evening. The agenda
is as always on our Wiki:

https://www.w3.org/community/hydra/wiki/Conference_Calls#2019-01-14


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

Miel, any chance one of you with better understanding of TPF/LDF will be there?

Regards

Karol Szczepanski

czw., 10 sty 2019 o 22:11 Karol Szczepański
<karol.szczepanski@gmail.com> napisał(a):

Miel, Ruben - it's great to see you guys around! I hope you'll stay
with us a bit longer

So this is also a reminder that the Hydra group has chosen
to serve as a vehicle for LDF standardization as well, in addition to Hydra Core.
Sure, I’m fine with discussing LDF/TPF within the CG.
The symptom of this close relation however is that I got the impression
on multiple occasions in the past that you are shaping Hydra Core specifically for LDF/TPF.
For me that is the crux of this matter as it potentially risks making Hydra less
appealing or less applicable to other usages.

I agree with both of you - I have no issues with having LDF/TPF on
board. I'd like just to keep a clean distinction between what belongs
to pure hydra, and what is an extension designed specifically for
LDF/TPF and what is LDF/TPF.

As such, I would strongly request not to close LDF issues (and they are all tagged with LDF).
No problem. There are 5 issues in scope:
- #98 Add picture to LDF/TPF specs - created February 2015 - no
activity. I'd gladly do it, but I'm not sure I have enough knowledge
about the topic. Anyone?
- #93 Clarify the reuse of the request URL inside of the fragment -
created January 2015 - same situation. Also reference to a mailing
list didn't help me much to understand what is the issue :(
- #77 Triple pattern fragments: explain how to handle blank nodes -
October 2014 - same here
- #65 Create a test suite for servers of triple pattern fragments -
July 2014 - and here

I've already reopened #56Date ranges / intervals for LDF with some
possible resolution, but we need your input in all those issues.
Otherwise these indeed are obsolete or abandoned.

Being tech-agnostic, Hydra should only serve as basis for more specialized tools,
defining common ground for various applications.
I think it’s very important to distinguish between Hydra and Hydra Core,
as we did in the past.
Interesting point, because personally I don’t feel like Hydra vs Hydra Core distinction is that clear.
More synonymical to be honest. And it has to be very clear, especially to newcomers
I agree with Tomasz. For me Hydra is Hydra Core (or was in the light
of what was written).

Anyway - feel free to elaborate more - I'll try to drive the
discussion so it reaches an end (whatever it is).

Best

Karol

czw., 10 sty 2019 o 08:42 Tomasz Pluskiewicz <tomasz@t-code.pl> napisał(a):



On 9 Jan 2019, at 23:48, Ruben Verborgh (UGent-imec) <Ruben.Verborgh@UGent.be> wrote:

Hi all,

First of all, a reminder that the Hydra Core Vocabulary and Linked Data Fragments are both part of Hydra
according to the website: http://www.hydra-cg.com/


As for the relation between Hydra and TPD/LDF, personally I think that too close relation is not healthy.

Indeed. There was never a call for a close relationship between Hydra Core (as we called it back then) and LDF.

However, what we _did_ decide, since LDF components were going to strongly depend on Hydra,
is that we would standardize LDF/TPF within the Hydra group.

So this is also a reminder that the Hydra group has chosen to serve as a vehicle for LDF standardization as well,
in addition to Hydra Core.

Sure, I’m fine with discussing LDF/TPF within the CG. The symptom of this close relation however is that I got the impression on multiple occasions in the past that you are shaping Hydra Core specifically for LDF/TPF.

For me that is the crux of this matter as it potentially risks making Hydra less appealing or less applicable to other usages.


Note that the LDF and TPF specifications are in the Hydra repository and on the Hydra website and namespace.

So whereas LDF issues are not in scope of Hydra Core, they are in scope of Hydra.
As such, I would strongly request not to close LDF issues (and they are all tagged with LDF).

Regardless of the Hydra vs TPF/LDF discussion, some of those issues have been sitting there for years on end. It is common in all kinds of software communities to cut off the long tail of potentially abandoned topics. If they are really of interest then there should be some concrete actions taken to resolving them. Otherwise they become and obstacle.


If we want LDF out of the Hydra group (which I am fine with), we should have that discussion first.
But at the moment, LDF is within Hydra, and the LDF issues are Hydra issues (but not Hydra Core issues).

That would not be my intention. Sorry if you understood it that way. Like Asbjorn and I proposed, we could create a new repository/-ies specific to LDF/TPF for the interested people to discuss related issues.


Being tech-agnostic, Hydra should only serve as basis for more specialized tools, defining common ground for various applications.

I think it’s very important to distinguish between Hydra and Hydra Core,
as we did in the past.

Interesting point, because personally I don’t feel like Hydra vs Hydra Core distinction is that clear. More synonymical to be honest. And it has to be very clear, especially to newcomers.


Best,

Ruben