Enable hydra to expect and return non RDF resources #200
Conversation
| @@ -253,7 +254,8 @@ | |||
| "label": "expects", | |||
| "comment": "The information expected by the Web API.", | |||
| "domain": "hydra:Operation", | |||
| "range": "hydra:Class", | |||
| "range": "hydra:Resource", | |||
| "rangeIncludes": ["hydra:Resource", "hydra:Class"], | |||
There was a problem hiding this comment.
I think it's redundant to repeat hydra:Resource here. In fact, a Resource itself is not useful as an object of expects/returns. It has to be something more specific, like Class
| "rangeIncludes": ["hydra:Resource", "hydra:Class"], | |
| "rangeIncludes": ["hydra:Class"], |
There was a problem hiding this comment.
I don't agree. I think it's useful to have both predicates to contain hydra:Resource. Previously used rdfs:range is more for compatibility, but I'd like to use schema:rangeIncludes in future implementations - it has weaker semantics.
I'd leave it as I suggested, at least untill some more specific alternatives are available.
There was a problem hiding this comment.
Isn't hydra:Resource what enables non-RDF payloads? I.e., won't hydra:Class restrict payloads to RDF?
There was a problem hiding this comment.
@asbjornu, schema:rangeIncludes doesn't have that strong semantics as rdfs:range. Putting only hydra:Class inside schema:rangeIncludes doesn't infer no other types can be used - it's more of a hint (well the name has it - range includes, but not restricts). Still, I'd prefer to have both so clients doesn't have to concatenate both rdfs:range and schema:rangeIncludes to discover what's actually allowed.
There was a problem hiding this comment.
I see. Thanks for the explanation, @alien-mcl!
There was a problem hiding this comment.
But Resource is range includes is actually not truthful. Most classes of Hydra are subclasses of hydra:Resource but they will not make sense as expects/returns. This hint is misleading.
| @@ -262,7 +264,8 @@ | |||
| "label": "returns", | |||
| "comment": "The information returned by the Web API on success", | |||
| "domain": "hydra:Operation", | |||
| "range": "hydra:Class", | |||
| "range": "hydra:Resource", | |||
| "rangeIncludes": ["hydra:Resource", "hydra:Class"], | |||
There was a problem hiding this comment.
Ditto
| "rangeIncludes": ["hydra:Resource", "hydra:Class"], | |
| "rangeIncludes": ["hydra:Class"], |
There was a problem hiding this comment.
Having discussed this again with @alien-mcl we came to an agreement how keeping hydra:Resource can actually be quite useful for a client and allow great flexibility at little cost.
Will expand in a prose PR explaining the client's behavior.
Summary
I've changed the
rdfs:rangeofhydra:expectsandhydra:returnspredicates fromhydra:Classtohydra:Resourceand introducedschema:rangeIncludesfor both.I've also mentioned that fact in the spec.
More details
This PR addresses issues #22 and #199 but does NOT resolves them. It is also an alternative approach to PRs #186 and #187.
Sole purpose is to enable the vocabulary to expect and return non-RDF resources. Previous specification placed a
hydra:Classin the range the proper predicates making it difficult to use other types of resources.Unfortunately, modification within the
rdfs:rangeof the aforementioned predicates may introduce possible issues within current implementations and specifications built on top of the vocabulary. Still, it seems to be the least intrusive method due to facts:hydra:Classused previously is still compliant with newly introducedhydra:Resourceschema:rangeIncludesintroduced does not apply strict RDF type entailing rules yet still provides semantic hints on possible values.