- 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>
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,
Dietrich
Received on Saturday, 10 January 2015 17:18:48 UTC