RE: Few concepts

On 8 Okt 2015 at 19:59, Karol Szczepański wrote:
> 1. The most annoying thing from my perspective is Hydra’s expect/returns
> predicates. In general, an operation returns (or expects) a class.

It expects/returns an instance of a class - that's how those properties are defined.

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

Why? That purely depends on how you define the properties. Following your line of thought, couldn't you make the same argument about rdfs:range/domain?

> 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

The former two are expressible today, the latter is indeed tricky at the moment.

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

You can do that today as well by creating a dedicated subclass to which you associate those additional descriptions.


> - it is possible to
> provide additional cardinality scenarios, i.e. whether single value or
> multiple values are expected;

Yep, we need something better in that regard.


> 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

You mentioned dictionaries/maps a few times by now (also in other threads). How do you see them to be expressed in RDF? Wouldn't they simply be a resource (subject) with multiple property/object pairs?

You raise a couple of valid points that we definitely need to address. The solution you propose doesn't convince me though. I think something like a shape (which the RDF Data Shapes WG is currently working on) that is also able to express things like binary blobs etc. would be a better fit for Hydra and easier for most developers to understand.


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

Please don't confuse hydra:Collection with a Java Collection or something similar. A Hydra Collection is not tied to those implementations in any way... but obviously they are similar.


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

I agree with all but the last sentence. That's also the reason why hydra:ApiDocumentation has been part of the vocabulary from the very beginning.


> 4. Reasoners - I don't expect the client (i.e. browser with JavaScript on
> board) to have a reasoner.

Agreed - depending on what exactly you classify as 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.

Well, everything is possible. What we need to do is to define what conformant Hydra clients MUST understand.


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

+1


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

Thanks a lot for writing this down. I think we are mostly on the same page. I look forward to your input in the discussions we will have about each of those points while fleshing out the design of the vocabulary.


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 8 October 2015 20:03:36 UTC