- From: Antoine Zimmermann <antoine.zimmermann@insa-lyon.fr>
- Date: Mon, 11 Apr 2011 14:12:24 +0200
- CC: RDF WG <public-rdf-wg@w3.org>
See below. Le 08/04/2011 19:24, Sandro Hawke a écrit : > On Fri, 2011-04-08 at 19:06 +0200, Dan Brickley wrote: >> On 8 April 2011 18:55, Sandro Hawke<sandro@w3.org> wrote: >>> On Fri, 2011-04-08 at 13:27 +0100, Richard Cyganiak wrote: >>>> On 8 Apr 2011, at 12:38, Nathan wrote: >>>>> Rather than strictly deprecating certain features, can we modularize them in to another "extensions" specification, or working note, perhaps together with steps publishers / consumers can take to factor them out? >>>>> >>>>> Else, are we versioning "RDF" such that people can tell, oh this is RDF 1 which supports x,y,z and this is RDF 1.x which does not? >>>> >>>> At the Stanford workshop there was a lot of talk about “weak deprecation”, meaning something like: Conforming implementations MUST still support it, but newly created data SHOULD NOT use it. There is no intention of removing the feature entirely in a future version of the spec. >>>> >>>> Going much further than that probably is not desirable, nor really possible given the constraints set by the charter. >>> >>> When I was writing up these issues, I started to use the term "weakly >>> deprecate", then I stopped and looked up the word "deprecate": >>> >>> In computer software or authoring programs standards and >>> documentation, the term deprecation is applied to software >>> features that are superseded and should be avoided. Although >>> deprecated features remain in the current version, their use may >>> raise warning messages recommending alternative practices, and >>> deprecation may indicate that the feature will be removed in the >>> future. Features are deprecated—rather than being removed—in >>> order to provide backward compatibility and give programmers who >>> have used the feature time to bring their code into compliance >>> with the new standard. >>> >>> -- http://en.wikipedia.org/wiki/Deprecation >>> >>> Isn't this exactly what we mean? We could deprecate rdf:Seq but say we >>> wont remove it for at least 99 more years. >>> >>> For some reason, though, everyone seems to think "deprecate" means >>> "remove". So maybe we do have to make up some new word. I'd rather >>> just be clear about them being "deprecated-not-removed". >> >> So that makes sense for software, and software-related features such >> as "does an RDF/XML parser need to do anything special for reification >> or rdf:Seq vocabs?". >> >> For *data* (and data should outlive software by years), I find this >> uncomfortable. Properties and classes generally just mean whatever >> they mean. Their use in various patterns passes in and out of fashion, >> but I don't find it quite comparable to software. Documents generally >> aren't maintained the same way... > > I can't see the distinction you're making. > > If rdf:Alt is deprecated, it means we suggest you not use it in data you > produce, but of course all software must still support it. If rdf:Alt > is removed, then software will no longer support it, so you really can't > use it in your data. Nothing in RDF can prevent anyone from using a valid URI as the name of a class. If rdf:Alt (resp Bag, Seq) was removed from the spec, it would hardly have any impact because rdf:Alt carries very little semantics. Tools can perfectly continue to support rdf:Alt in some way or others because tools can have specific treatments for specific URIs (e.g., foaf:knows) and still be qualified as conformant. > > I think your argument that data is not maintained suggests we should > probably say that features will NEVER be removed, just deprecated. > > But given that most of us misunderstood what deprecated meant in this > context (including myself), I can live with 'archaic' or something else. > > In practice, there may be an issue with software cutting corners on > features they know are deprecated/archaic; I think our best option is to > just be clear -- to say we suggest Feature X no longer be used in new > systems, but note that Big Product A and Popular Product B do use it, so > it's important that software still support it. +1 IMO, there is absolutely no problem deprecating containers and reification in that way. -- Antoine Zimmermann Researcher at: Laboratoire d'InfoRmatique en Image et Systèmes d'information Database Group 7 Avenue Jean Capelle 69621 Villeurbanne Cedex France Tel: +33(0)4 72 43 61 74 - Fax: +33(0)4 72 43 87 13 Lecturer at: Institut National des Sciences Appliquées de Lyon 20 Avenue Albert Einstein 69621 Villeurbanne Cedex France antoine.zimmermann@insa-lyon.fr http://zimmer.aprilfoolsreview.com/
Received on Monday, 11 April 2011 12:12:52 UTC