W3C home > Mailing lists > Public > public-hydra@w3.org > January 2015

Re: remove hydra:Resource and hydra:Class

From: Dietrich Schulten <ds@escalon.de>
Date: Wed, 07 Jan 2015 10:39:06 +0100
Message-ID: <54ACFEBA.1060607@escalon.de>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 09:39:44 UTC