W3C home > Mailing lists > Public > public-hydra@w3.org > January 2015

Re: Enumeration values

From: Dietrich Schulten <ds@escalon.de>
Date: Sat, 10 Jan 2015 18:18:19 +0100
To: Tomasz Pluskiewicz <tomasz@t-code.pl>, <public-hydra@w3.org>
Message-ID: <14ad4da8778.2860.78a08d5134d8b1c7d32e1da05a71bfd3@escalon.de>

On January 10, 2015 3:26:39 PM Tomasz Pluskiewicz <tomasz@t-code.pl> wrote:

> On 2015-01-10 14:17, Thomas Hoppe wrote:

> > Also I want to stress again that we also need
> > to be able to link to some external resource:
> >
> > "hydra:allowedIndividuals": {
> >    "@id": "https://example.com/event_status/"
> > }
> >
> > This could be a normal API resource, a hydra collection probably.
> > But also in this case, It would be awkward if every item in this collection
> > would need to have an `hydra:allowedIndividual` property.
> >
> Ah yes, I like where this is going. I was myself about to write about a
> case where the individuals are filtered by the user. Think auto-complete
> <select /> as a common example.
> How would it be possible to reuse (templated) links as an option for
> remote source of available individuals? Also would we restrict the
> response somehow to hydra:Collection?

That is why I added a third property allowedResource whose range would be 
an IriTemplate returning a Collection, after the first feedback from Ruben. 
I reworked the #82 text quite a bit now to reflect our discussion, please 
take a look.

I agree that this dynamic list of items is a third requirement to cover, I 
also had auto-complete in mind.

Another question is certainly how we tell the client which kind of allowed 
items it is looking at. Is it preferable to have multiple properties, each 
with their own range - or one property with various possible types and the 
client must look at the @type?

Best regards,
Received on Saturday, 10 January 2015 17:18:48 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 10 January 2015 17:18:49 UTC