Re: remove hydra:Resource and hydra:Class

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 05.01.2015 um 12:58 schrieb Ruben Verborgh:
> Dear all,
> 
> 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”
> [1].
> 
> 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? If we all agree, I can make the necessary
> edits to the spec.
> 
> Best,
> 
> Ruben
> 
> [1] http://www.w3.org/TR/rdf-schema/#ch_resource
> 

That seems an incompatible change, so it will break existing
implementations. Since that won't be the last time that an
incompatible change happens - does it make sense to introduce some
versioning scheme, e.g. add date information to the hydra URL, like

"hydra": "http://www.w3.org/2015/01/ns/hydra/core#"

and keep the old version around as

"hydra": "http://www.w3.org/2014/12/ns/hydra/core#"

The un-dated url is probably always the latest version.

So implementations could choose in the future when to use the latest
version and not break immediately. Everything will break after the new
version without hydra:Resource and hydra:Class becomes available, but
as an implementor one can fix that quickly by changing the hydra term
to the version dated 2014/12 and then implement the changes when possible.

Best regards,
Dietrich





- -- 
Dietrich Schulten
Escalon System-Entwicklung
Bubenhalde 10
74199 Untergruppenbach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iEYEARECAAYFAlSr8Q8ACgkQuKLNitGfiZPE0ACgmFhUN4Qvt7hFKxketv4wjdXb
TEAAn043dkhZFM7tFLAFkk8ab5My+0Ex
=/AIK
-----END PGP SIGNATURE-----

Received on Tuesday, 6 January 2015 14:29:07 UTC