Re: Client POC

Hi Thomas

Thank you for your feedback.
>> - class description in general uses OWL restrictions on properties - not 
>> very convinient
>I hope that SHACL can be used for this in the future.
I hope so. I'm just wondering how to have Hydra + SHACL working together 
without confusing the client (hydra:Class, hydra:SupportedProperty, 
rdf:Property, schacl:Shape, etc.)

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

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

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

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

Best

Karol

Received on Monday, 9 November 2015 20:50:58 UTC