Re: Client POC

>>>> - operations returns or expects anonymous sub classes of their 
>>>> respective classes to provide additional contextual details, like how a 
>>>> given class functions as an expected instance
>>>> - custom predicate is introduced to denote that a single value is 
>>>> expected/returned; if not set multiple instances are assumed
>>> Also cardinality should be covered by SHACL.
>> Actually I didn't find any suitable construct. Indeed SHACL addresses 
>> cardinality when it comes to classe's property restriction, but here we 
>> tell the client on how many instances an operation returns.
>Mhh, I never had this requirement, the client should just take what it gets 
>and react accordingly I think.
Unfortunately, in business applications it's a commont approach i.e. to 
display a grid that will be filled with and optional progress. In order to 
achieve that client should know in advance what to expect.

>>>> - I'm using owl:InverseFunctionalProperty to mark classe's property as 
>>>> a primary key one; it's not elegant as for datatypes this moves whole 
>>>> RDF to OWL Full, but for the time beeing let it be that way
>>> Why do you need to tell the client?
>> It happens that users would like to have that i.e. in the entities grid 
>> or somewhere else.
>Same for this. I always use the IRI (or the local part of it) as primary 
>key from client all the way down to the database.
>I think that makes life easier and is consistent.
In RDF yes, IRI is a good key, but for old-school CWA approaches it's not. 
Also, IRI is not always a good one - sometimes IRI is just an consequence of 
some additional processing (i.e. base Uri concatenated with that primary key 
of the entity), i.e. http://my.api/users/<user_name>

>>>> 1. API Documentation model gives a lot of freedom. I think it's too 
>>>> much of it. I already had that conversation with Ruben that sticking to 
>>>> RDFS/OWL we put a lot of burdain on the clients. This is indeed the 
>>>> case. Example: in order to express that an operation returns single 
>>>> instance of a given type I used Markus' suggestion to use a subclass of 
>>>> that type with few extension predicates to denote cardinality details. 
>>>> Hydra doesn't give any way of expressing that (or no obvious way), and 
>>>> as an alternative to what I've used would be using a hydra:Collection 
>>>> as a returns but we'd loose information on what type of the members 
>>>> are.
>>> With the new collection design [1] you would not loose semantic 
>>> fidelity.
>> Latest spec doesn't have anything to bind the member type with neither 
>> collection nor it's view - this would be required in order to use a 
>> hydra:Collection as a returned type.
>I hope we will solve this issue [1] next.
Looking forward for that.

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

Karol

Received on Wednesday, 11 November 2015 14:57:46 UTC