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

Re: Enumeration values

From: Thomas Hoppe <thomas.hoppe@n-fuse.de>
Date: Mon, 12 Jan 2015 10:35:33 +0100
Message-ID: <54B39565.1040708@n-fuse.de>
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 

>> 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

This archive was generated by hypermail 2.3.1 : Monday, 12 January 2015 09:36:02 UTC