Re: moving forward—with a plan

Hey Ruben and hydrarians,

there is a way forward, but it requires this community to re-evaluate
it's design goals.

We have produced an abstract model for ontology-driven read-write
Linked Data, which we call Linked Data Templates and will soon
contribute as a specification via the Declarative Linked Data Apps CG.

Here is the paper for the upcoming XML London conference (try
downloading PDF, GitHub viewer is low quality):
https://github.com/AtomGraph/Linked-Data-Templates/tree/master/XML%20London%202016%20paper

It is based on URI-SPARQL mapping as a function, which can be
expressed declaratively as a template and used in ontologies that
drive LD applications. The article only goes through the very basics,
the specification will be more detailed and extensive.

Ontology-driven apps were actually the original Semantic Web vision,
so this is very much going back to the roots (couldn't find a free
version):
http://www.scientificamerican.com/article/the-semantic-web/

This requires doing things right even if they're hard: focusing not on
secondary/orthogonal things like syntax (JSON-LD) but on abstract
models (RDF, OWL, SPARQL), not on "lightweight" vocabularies but on
formal ontologies, not on creating new specs but on combining existing
ones. Because trends like formats and even programming languages come
and go, but theory is here to stay.

So there is a way that can bring us closer to the web of data, and it
is demonstrated to work. It's up to you to see if you can put the
differences between Hydra and LDT behind you in order to work together
on a common goal.


Martynas
atomgraph.com

On Wed, May 18, 2016 at 11:37 AM, Ruben Verborgh
<ruben.verborgh@ugent.be> wrote:
> Dear Hydra community,
>
> My group at Ghent University–iMinds has been particularly interested in the hypermedia control aspect of the Hydra Core Vocabulary. The idea that you could semantically describe in-band what fields a client can use, and how these fields influence the response, is valuable for many applications. Unfortunately, the Core Vocabulary hasn't been progressing lately, and with this mail, I want to start a change.
>
> As you know, our primary application has been the Linked Data Fragments family of technologies. Here, hypermedia controls are used to explain to a client "this is what you can do", or more precisely "you can use these controls to filter the collection of data in this way". I always insisted on the use of the Hydra Core Vocabulary, as building a specific vocabulary to fit my use case would kind of void its purpose. Furthermore, I believe that the use case of filtering things is sufficiently generic to be tackled at a higher level.
>
> Our use cases are starting to move at a higher speed now, with different people actively developing different variations of the interface. Such variations only make sense if we can describe to clients what is going on. Unfortunately, the Hydra Core Vocabulary currently cannot keep up. We could interpret this in two ways: either we are moving too fast, or Hydra is moving too slow. Of course, all of us here have done our best to keep things moving. A particular attempt at this is the very long thread about filters. Yet after months of work, and the feeling we are almost there, nothing has materialized.
>
> We could see this as a sign we need to resurrect that thread, but I doubt this is what's really needed. What I think we need is a different way of managing the Hydra effort altogether. Perhaps we need weekly, bi-weekly, or monthly calls. Perhaps we need a steering committee or dedicated task force. But I need to see Hydra move at a sustainable pace, with clear milestones, deliverables, and commitment. Otherwise, we'll have no choice but to pursue other paths—and that would be a shame. I'm more than willing to invest time in Hydra, but then I need to be able to see where we are going, and when.
>
> Things don't need to happen right away—for instance, we could take the summer off to think, and restart in September or so. But I think we need a solid plan.
>
> Looking forward to your feedback!
>
> Ruben

Received on Thursday, 19 May 2016 12:08:46 UTC