Re: remove hydra:Resource and hydra:Class

Hi Dietrich,

> it would break when clients relied on the promise that they can
> dereference a hydra:Resource.

We don't break that promise.
All things that were hydra:Resource will still be dereferenceable;
like all things in commonly used ontologies are anyway.

> When the server suddenly stops marking
> links with that type, they would wrongly assume that they should no
> longer dereference the link.

They were never allowed to assume that in the first place.
First of all, it is an open world, so the absence of a type
allows us to conclude nothing about its presence elsewhere.

Furthermore, none of the dereferenceable things in other ontologies
are marked as dereferenceable, yet they still dereference.

It's like I explained previously:
if we don't know whether something is dereferenceable, we just try to dereference it.
If we are certain something is dereferenceable, we still try to dereference it.
The procedure of checking dereferenceabilty and actually doing it is thus exactly the same.
Nothing is gained or lost by marking dereferenceability.

> Why do you think that removing a concept is not an incompatible
> change? I would assume it always is.

hydra:Resource simply means:
1. the thing is an rdfs:Resource
2. it is dereferenceable

Whether or not we explicitly mark Hydra resources as such
doesn't change the above two facts. Hence, we remain compatible.

That, and the fact that no external system uses hydra:Resource or hydra:Class.

> John's approach to deprecate old stuff makes sense. How about
> deprecating hydra:Resource and hydra:Class, then?

I would remove, because they are (needlessly) used in the modeling.
Furthermore, our own ontology is the only one that uses it.
It's bloat—I think we need to get rid of it while we still can.

Note that changes such as repurposing hydra:writeonly to hydra:writeable
had far more consequences, yet we didn't use deprecation either.

Best,

Ruben

Received on Wednesday, 7 January 2015 10:53:30 UTC