Re: Enumeration values

Hi Tomasz,

Am 11.01.2015 um 12:31 schrieb Tomasz Pluskiewicz:
> 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. 

I have added an illustration for allowedResource with IriTemplate to 
#82, see jsonld playground http://tinyurl.com/px4aj75. The idea is that 
instead of the :IriTemplate in the playground the value of 
allowedResource could also be a simple link, like

             "hydra:allowedResource": {
               "@id": 
"http://localhost:8180/webapp/hypermedia-api/countries",
               "@type": "hydra:Resource"
             }

As long as we have :Resource, I thought I'd use it - who knows when 
it'll be gone :))
Here it comes in handy to give the client a hint that this is not an 
:IriTemplate, to whom it may concern.

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

>
> 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.
>
> This way I see it would be possible to mix inline values, values 
> provided by the server and user input (for literals).

Suggestions are slightly different from the constraints I had in mind. 
Would it make sense to handle suggestions separately from allowed values?

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

I am unsure how to make the trade-off. In one case the client has to 
check for the presence of three different properties to find out if 
there are any constraints, but if it finds any, the treatment is clear 
for each property. In the case of a single property it knows right away 
that there are constraints but we have to be explicit about the @type 
which makes for a more noisy response body and is not fully consistent 
since for literals we couldn't set an @type.

Other issues: a json-ld array has no defined order in the underlying 
rdf. Is that a problem for our purpose? Should we model the allowed 
values more like owl:Restriction, i.e. as a class which is defined in 
terms of a set of individuals? How would that fit in with the 
@type:@vocab feature of json-ld?

I find it quite enlightening to discuss these practical problems, I also 
hope we can provide valuable input to the Resource Shapes WG, from the 
implementer's POV.

Cheers,
Dietrich

Received on Wednesday, 14 January 2015 20:32:44 UTC