Few concepts

In regards to these posts: 
https://lists.w3.org/Archives/Public/public-hydra/2015Oct/0090.html and 
https://lists.w3.org/Archives/Public/public-hydra/2015Oct/0087.html I’d like 
to share few of my ideas or concepts on possible Hydra development.

First of all, I’m not an ontologist, but I’ve got some background on OWL and 
I’m quite fluent RDF user and tried to implement few things also with Hydra 
here and there, thus I hope for interesting feedback. All examples I’ll 
bring here are in turtle with prefix pointing as follows: hydra – Hydra 
namespace, schema: Schema.org namespace, my – whatever namespace, 
imaginary - possible Hydra extension.

1. The most annoying thing from my perspective is Hydra’s expect/returns 
predicates. In general, an operation returns (or expects) a class. I think 
this is most unfortunate as first thoughs are that it expects a class 
definition. This is not the case – it expects a resource that is of a given 
class. And here is my issue with current implementation. Instead of having:
my:restOperation a hydra:Operation.
my:restOperation hydra:expects schema:Action.

I’d prefer:
my:restOperation a hydra:Operation.
my:restOperation hydra:expects _:someResource.
_:someResource a hydra:Resource.
_:someResource imaginary:ofClass schema:Action.

This approach is more consistant from ontological point of view. I think it 
also seems more logical - operation expects a resource that matches some 
criterias, in this case it's of a specific class. It gives quite a lot of 
additional benefits:
- it is possible to provide various criterias, i.e.: ofClass for complete 
RDF statements, ofDataType for single literals or ofMediaType for non-RDF 
resources
- it is possible to provide additional contextual description of the 
expected/returned funcional meaning i.e. api documentation can provide a 
textual human readable description of what is expected/returned without 
binding that description to the actual class or resource itself
- it is possible to provide additional cardinality scenarios, i.e. whether 
single value or multiple values are expected; an ontology can provide 
cardinality constraints and ignoring them in the hypermedia controls or api 
documentation will cause the client to fail when sending incorrect data by 
design; from UI point of view it is also crucial to have these details to 
generate a valid view
- it is possible to provide additional logical constrains; while RDF lists 
are pretty well supported, C# dictionary/Java map data structures are 
somehow ignored while still quite heavily used
- it is possible to provide list of allowed values for enumeration scenarios

2. Collections - while discussion about these is still unfinished, let me 
share my point of view on this subject.
>From data processing point of view, I don't really care whether it is a 
collection or other data structure - I do care on what I can do with it. I 
believe that templated links and few hydra:freetextQuery like predicates 
could completely describe basic operations on data structures (i.e. 
imaginary hydra:take for limit, hydra:offset for offset, hydra:orderBy for 
ordering - this one will need some more attention). Additional details like 
first/last page could come in handy for the client, but I think it's more 
important to know how and what to do than what am I actually working on. 
This approach could also cover dictionaries.
Also with this approach I don't have to expose to the outside world my 
internal implementation - I don't have to say that given resource is 
actually a collection. Otherwise client could imply on something I wouldn't 
like it to imply.

3. HTTP - while the HTTP spec allows client to discover stuff on-the-fly, I 
think that it could be nice to have some more details in API documentation 
in advance. I don't want client application with UI controlled by human to 
wait ages for the background tasks to discover that given request is allowed 
with these headers or that method or whatever HTTP constraints we can 
imagine. I'd prefer to have these details downloaded in the initialization 
stage, setup an application and limit the UI and user himself from doing 
something that won't work by design. Application will have to poke 
exceptional situations, indeed and additional HTTP/Hydra details discoverd 
later will help recovering from such situations, but developing an UI 
application without precomputational stage won't work.

4. Reasoners - I don't expect the client (i.e. browser with JavaScript on 
board) to have a reasoner. Unfortunately, Hydra uses OWL/RDFS elements here 
and there enabling very complicated logical construct to be in place. 
Example: hydra:property has a range of rdf:Property and this class can have 
in it's range an owl:Restriction - this is the shortest path to problems. I 
think we should consider moving to something that is simpler. I don't impose 
that we should i.e. adopt SHACL, but i understand this initiative as an OWL 
'free' way of describing data structures in RDF. We cannot cut ourselves 
from the OWL totaly as everywhere owl:Class appears either in range or 
domain, bu I think we should minimize situations when reasoner would be the 
only option for the client.

Phew - I think I covered everything for now that was a salt in my eye. 
Please feel free to elaborate on these thoughts.

Regards

Karol Szczepański

Received on Thursday, 8 October 2015 17:59:29 UTC