Re: Client POC

Hi Dietrich,

I have forgot about your issue but it is indeed related to that matters.
As you mention, the hydra:allowedLiteral of your proposal addresses eums 
(individuals or literals from a predefined fixed range).
The hydra:allowedResource is more or less what I had in mind.
I also think that we need both. Below I try to reason why.

Commenting on Ruben's answer to your proposal on the list this:

> For example: foaf:knows has a range of foaf:Person.
> If we're developing a social application,
> it might make sense to restrict this to only people on the network.
> Yet listing them exhaustively would probably not make sense.
> So then perhaps a ex:knows (subproperty of foaf:knows)
> where the range is “people from the network” makes sense.

I think this is still to short reaching. Only the fact that there is a 
property with a property
having a certain range and the existence of resources of that type in an 
API under a certain
domain (or sub-domain?!) is
1.) too many deductions (also technologically too complex if we specify 
this in OWL)
2.) In many real life cases insufficient to express the relation 
logically correct.
For example, there might be an operation where a
a foaf:Person is expected (e. g. as a value of a property) and there is 
a /persons/ resource.
Based on the business logic for that very app, it happens that only a 
subset of the readable persons is applicable.
In such a case, additional knowledge is required by the client.
A dedicated property which provides an IRI with a filter statement (e. 
g. /persons/?role=onlythisrole)
would solve this elegantly.

BG, Thomas

On 11/13/2015 11:29 PM, Dietrich Schulten wrote:
>
> 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
>

Received on Tuesday, 17 November 2015 07:07:18 UTC