Remove hydra:Resource and hydra:Class

[lanthaler]

_Raised by Ruben Verborgh on the mailing list_:

For reasons of simplicity and vocabulary reuse, could we remove hydra:Resource and hydra:Class?

Right now, everything in the Hydra Core Vocabulary is a hydra:Resource, and all classes are hydra:Class.

The only difference between hydra:Resource and rdfs:Resource is that hydra:Resource instances are dereferenceable; and rdfs:Resource itself adds no semantics whatsoever, since “all things described by RDF are instances of the class rdfs:Resource” [RDFS].

Dereferenceability is orthogonal to ontological relationships, and should IMHO be a recommended practice in the spec rather than an ontological relationship. It does not add anything at all:

• If a client wants to dereference, the absence of hydra:Resource does not mean something is not dereferenceable.
• If a client wants to dereference a hydra:Resource, it takes the exact same steps it would for something that is not explicitly labeled a hydra:Resource.
• The only difference is the “guarantee” offered by the ontology that something is dereferenceable; but actually doing the dereferencing and finding out whether something is dereferenceable involves the exact same step, i.e., GETting the thing. No gain there.

In addition, hydra:Class is simply the disjunction of hydra:Resource and rdfs:Class, so by the above reasoning, we can simply make it rdfs:Class.

It seems to me that hydra:Resource and hydra:Class are artifacts of something that no longer has importance. I therefore propose to simplify and clarify the ontology by:

• removing hydra:Resource and mentions of it;
• removing hydra:Class and replace mentions of it by rdfs:Class.

If necessary, we can add something to the spec about dereferencing, but I don't think that this would add something.

Any thoughts on this?

[vanthome]

Having used Hydra and other vocabs for a while now, I opt for removing the following elements from the vocab:

• hydra:Resource
• hydra:Class
• hydra:title
• hydra:descriptions

The reason for the former both is exactly what Markus outlined in the issue above (and previously has been discussed in the CG). The latter two provide no added semantics at all over established properties like dct:label dct:description.

[asbjornu]

I agree. Wherever and whenever we can reuse existing ontologies, we should.

[alien-mcl]

I believe this issue is somehow outdated. In recent changes we've modified ranges and domains of several predicates (i.e. rdf:Resource in favour of hydra:Resource as the dereferencable requirement is removed (as it was broken from the beginning). The hydra:Class is still there acting as a glue of all hydra defined concepts and hydra:Resource is left acting for developers as a promise that heir API's resources are, well, dereferencable.

As for the hydra:title and hydra:description I still see some use cases - these usually will be API specific, thus in case an API reuses some terms from other vocabularies, using hydra specific predicates will narrow their applicability only to that very API (in case some data aggregators will crawl those data).

I'd leave those terms as they are.

[tpluscode]

After careful consideration, I support @alien-mcl in keeping all of these terms

hydra:Resource

I think it's now well established that hydra:Resource denotes explicit promise dereferencability (regardless of the server will actually respond successfully). Thus, it is quite useful in itself.

For example, in my APIs, I have been using this also on the server, where any resource which is typed as hydra:Resource is indeed directly served using a generic handler.

hydra:Class

While I have not been relying much on this class so far, I would also like to keep it. I plan to build APIs which the server dynamically discovers its capabilities by looking up instances of hydra:Class from a store. In this scenario, every such instance is a separate resource and adding or removing hydra:Class would serve as a form of feature toggling.

hydra:title/hydra:description

Also here, I think these terms have their place. Analogous to sh:name and sh:description from SHACL, these are quite useful in providing app-specific labels specifically for the use on the UI, where any rdfs:label and the like could be inappropriate. That would be the case especially when an API is dynamically composed of existing vocabularies.

[alien-mcl]

I think we can close it - I don't see any objections regarding latest discussion