RE: Why the collection?

On Tuesday, March 10, 2015 12:13 AM, Jacopo Scazzosi wrote:
> On Mon, Mar 9, 2015 at 10:18 PM, Markus Lanthaler wrote:
>> What is context-specific about them?  Would you argue that lists
>> (think rdf:List) are context-specific as well?
> 
> No, rdf:List doesn't look as context-specific nor nearly as powerful
> as  hydra:Collection.

So what makes Hydra collections context-specific that doesn't make RDF lists context-specific?


>> That's the thing, you need such a concept to realize even the simplest
>> APIs. I think it would be a huge mistake to leave the design of such a
>> building block as "an exercise for the reader".
> 
> I've been specifically asked to implement LD collections so as to make
> them as similar as possible to plain JSON arrays. The greater the
> difference from [...], the bigger problem I have. I do realise that
> this might  not be a common constraint but it's one I'm dealing with
> atm (and one that  leads to simpler representations, which I
> personally prefer). Hydra's design  seems to be getting further and
> further away from that.

I see. So, you still want to give the collection itself a URL, right? In that case, the simplest JSON shape for the collection looks somewhat like this:

  {
     "@id": "/collection",
     "member": [ ... ]
  }

Right? Now all we do is to add more metadata for machines to that construct. It depends on your application on how much of it you need/want. For instance, if you don't depend on a vocabulary which uses RDF inferences (rdfs:range), you don't have to use hydra:manages. If you need to split your collection into pages, then obviously this complicates things... and in my opinion the representation should be clear about this. It's easier for people (and machines) to understand these things if they are expressed explicitly instead of relying on implicit assumptions or inferences.


> I am slowly coming up with an alternative design using ranges instead
> of  pages, though, and it's hitting "close enough" to the expected
> result.  I started out way off-track (this stuff feels like rocket
> science, every now  and then) but I'm getting there.

Do you have something that you can share with us? I'm highly interested in what you came up with.


> My considerations come from the fact that I'm already able to describe
> the  supported operations of an instance of this design of mine using
> Hydra's  current vocab, as proven by the fact that I've had a non-dev
> teammate add  a new item to it using the Hydra Console.

Cool!


> Now, I'm not
> saying that the  current collection design is wrong. On the very
> contrary, I'd be ready to bet  that it's a lot better than mine.
> However, I just can't use it because my  specific context mandates
> simpler, more immediate representations. I also get the feeling that
> I'm not the only one in this situation.
> 
> So, I partially agree with the fact that Hydra should not leave too
> much to the reader. I do also think, however, that hydra:Collection is
> actually too close to the other side of the spectrum.

What aspects of the design worry you exactly?


P.S.: Text-only mails are generally preferred on mailing lists. Thanks :-)


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 11 March 2015 21:32:36 UTC