Re: Enumeration values

On 2015-01-10 18:18, Dietrich Schulten wrote:
>
>
> 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 see. Could you extend the issue text with some example of how you 
would use the allowedResource. Based on the current description I 
understand that alloweLiteral, allowedResource and allowedIndividual 
would all come at the same level under Property? How about a single 
allowedValue property, which would expect various objects for 
individuals and such?

And by the way the allowedResource doesn't necessary have to accept a 
template. It could be simply a link to GET so that a list of possible 
values is fetched on demand.

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

I was also just now thinking about a way to allow free-text input along 
with suggested values. Something like most recently used values etc. So 
it's like an auto-complete where user can also supply a value not 
included in the suggestions. I'm not sure how to model this though.

{
   "@type": "hydra:Property",
   "hydra:allowedValue": [
   {
     "hydra:literal": "last used text"
   },
   {
     "hydra:literal": "another recent input
   },
   {
     // a value to indicate that any other literal is allowed
     "@id": "hydra:FreeText"
   },
   {
     // property just an example now
     "hydra:resource": {
       // IriTemplate or resource
     }
   }]
}

This way I see it would be possible to mix inline values, values 
provided by the server and user input (for literals).

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

I seem to have answered this question above without reading and 
understanding first. I think that an allowedValues property is also a 
single potential extension point for implementors. If it all were under 
Property I'd find it messy.

> Best regards,
> Dietrich
>
>

Received on Sunday, 11 January 2015 11:32:28 UTC