Re: Client POC

A while back we were toying with the idea of a mechanism for dynamic lists of allowed values coming from the backend: 

https://github.com/HydraCG/Specifications/issues/82

At the time we stopped the discussion to see what SHACL will bring. I still think it would be a cool feature. 

Certainly part of the discussion how we can describe expected values.

Best regards, 
Dietrich 

Am 13.11.2015 22:24 schrieb Thomas Hoppe <thomas.hoppe@n-fuse.de>:

On 11/11/2015 03:57 PM, Karol Szczepański wrote:
>>>>> - currently, all properties are literals; if having properties 
>>>>> with relations to other resources, question araises of how to tell 
>>>>> the client on where to get the values from; if no explicit pointer 
>>>>> is set client may search the API documentation for a given 
>>>>> supported class and try to find a suitable method, but something 
>>>>> explicitely defined may disambiguate it (i.e. custom 
>>>>> search-as-you-type operation accepting an user input that will be 
>>>>> use as a free text query). Something like OWLs allValuesFrom but 
>>>>> pointing to an operation might come in handy.
>>>> I solve this by the context. If a value is a relation, I just do:
>>>> creator:{
>>>> @type:"@id",
>>>> @id:"dct:creator"
>>>> }
>>>> vs.
>>>> creator:"dct:creator"
>>>> if its just a literal.
>>> I'm not sure how does it fit to the improvement suggested. Type 
>>> coertion says the client that a value should be expanded into an 
>>> IRI, but it's just an JSON-LD feature.
>>> I would like to bind a custom operation to be used by client when 
>>> obtaining possible values for an object relation (in OWL). I was 
>>> thinking about using hydra:operations of a hydra:Resource (of which 
>>> type is hydra:SupportedProperty), but it wouldn't be contextual.
>> It's a JSON-LD feature yes, i just tried to translate it into other 
>> serializations and it's indeed not possible.
>> I don't quite understand this. You want to point the client to an 
>> operation it can call to obtain possible values as far as I understand?
> Yes. Imagine a situation that you want to create an edit form for 
> entity of type Product and that type defines a property named 
> Category, which accepts as an value another resource of type Category. 
> In business applications it's quite a common approach to have a simple 
> text-box that shows a list of entities matching a given text on 
> search-as-you-type behavior. I could imagine that a property Category 
> could define an operation that client could use for that purpose. I 
> was thinking about using hydra:Resource's hydra:operation predicate to 
> have that connection between hydra:SupportedProperty instance and 
> hydra:Operation instance. 

Yes, that's definitely a common case, I currently have this in many 
situations and the intelligence to make this connection is baked into 
the client.
The "best" idea I came up with so far is to leverage rdfs:domain and 
rdfs:range of a class definition (be it in a an API resource or even a 
vocabulary).
But this is of course too narrow.
Hmm, a property defining an operation does not sound straight forward to 
me and with the current means of hydra this would not be possible to 
express.
However I can image a construct in hydra, maybe not in core but maybe in 
an accompanying vocab where we would have a predicate
that allows to point to an operation that can provide possible values 
for a given property.
What do you think?

BG, Thomas