W3C home > Mailing lists > Public > public-hydra@w3.org > November 2015

Re: Client POC

From: Karol Szczepański <karol.szczepanski@gmail.com>
Date: Mon, 9 Nov 2015 21:50:32 +0100
Message-ID: <C3031398CC3C433B8497F5FCA0BCE56E@Alien>
To: <public-hydra@w3.org>, "Thomas Hoppe" <thomas.hoppe@n-fuse.de>
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

This archive was generated by hypermail 2.3.1 : Monday, 9 November 2015 20:50:58 UTC