- From: Dietrich Schulten <ds@escalon.de>
- Date: Wed, 07 Jan 2015 10:39:06 +0100
- To: public-hydra@w3.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 06.01.2015 um 16:35 schrieb John Walker: >> On January 6, 2015 at 3:44 PM Ruben Verborgh >> <ruben.verborgh@ugent.be> wrote: >> >> >>> That seems an incompatible change, so it will break existing >>> implementations. >> >> It would most definitely not. Where would it break? E.g. it would break when clients relied on the promise that they can dereference a hydra:Resource. When the server suddenly stops marking links with that type, they would wrongly assume that they should no longer dereference the link. Why do you think that removing a concept is not an incompatible change? I would assume it always is. >> >>> 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#" >> >> That's how FOAF got stuck with http://xmlns.com/foaf/0.1/ ;-) >> It appears to me we have more strict compatibility requirements than foaf since we must assume that implementations rely on the presence of all known hydra classes and properties. > > Indeed, putting version numbers into URIs is not *cool* in this > case. > > Having a versioned URI for the information resource where you can > get a certain snapshot/release of the vocabulary is all fine, but > the concept of hydra:Resource is *the same* thing across all > releases of the vocabulary so ideally the URI should also be the > same. If you change the definition of the concept sufficiently that > it is a breaking change, it should get a new URI and the old > concept marked as deprecated. Also don't re-use/re-purpose URIs for > a different concept. John's approach to deprecate old stuff makes sense. How about deprecating hydra:Resource and hydra:Class, then? Best regards, Dietrich - -- Dietrich Schulten Escalon System-Entwicklung Bubenhalde 10 74199 Untergruppenbach -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iEYEARECAAYFAlSs/roACgkQuKLNitGfiZN6yACeL0I8gUO6iIfA07wTPuLeodpK jHkAnjxBFh/52ZHDr/PDu1IwJsXmA0E0 =kx2S -----END PGP SIGNATURE-----
Received on Wednesday, 7 January 2015 09:39:43 UTC