Re: Client POC

Hi Karol,

Am 09.11.2015 um 21:50 schrieb Karol Szczepański:
> 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.

Mhh, I never had this requirement, the client should just take what it 
gets and react accordingly I think.

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

>
> Best
>
> Karol

[1] https://github.com/HydraCG/Specifications/issues/41

Received on Tuesday, 10 November 2015 16:34:28 UTC