- From: Thomas Hoppe <thomas.hoppe@n-fuse.de>
- Date: Mon, 12 Jan 2015 10:35:33 +0100
- To: public-hydra@w3.org
>> Or with properties from some domain specific vocab:
>>
>> "hydra:allowedIndividuals": [
>> {
>> "someVocab:eventStatus": "EventCancelled",
>> "rdfs:label": "manifestazione annullata"
>> },
>> {
>> "someVocab:eventStatus": "EventPostponed",
>> "rdfs:label": "manifestazione rinviata"
>> }
>> ]
>>
>
> What purpose does using some other predicate here serve? Will it have
> to be same as the property described? What if it is not. I find this
> an unnecessary complication for the client.
It might be useful for the client, if it understands
`someVocab:eventStatus` it could provide the user a better interface
than just showing the label for example.
With this I just wanted to show that I imagine
`hydra:allowedIndividuals` should take any kind of list/ collection of
resources.
>
>> 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.
Definitively... with an IRI template it should be simple to model the
auto-completion case.
I think this has been also mentioned in the follow-up from Dietrich.
>
> 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?
>
> Regards,
> Tom
Received on Monday, 12 January 2015 09:36:01 UTC