- From: Sean Bechhofer <sean.bechhofer@manchester.ac.uk>
- Date: Wed, 9 Apr 2008 13:12:04 +0100
- To: Sean Bechhofer <sean.bechhofer@manchester.ac.uk>
- Cc: SWD Working Group <public-swd-wg@w3.org>
On 7 Apr 2008, at 13:05, Sean Bechhofer wrote: > > > I've had a long standing action next to my name to propose a way to > handle deprecated properties. This is related to the task of producing > an RDF schema -- in particular whether we include the deprecated > properties as instances of, for example, owl:DeprecatedProperty. > > The deprecated vocabulary should be documented somewhere (in > Reference), but I do not see a great advantage in including the > vocabulary in the RDF schema. Rather, I would see that it could lead > to additional "clutter" in the schema. As this is the first "official" > description of the vocabulary, I would like to start with as clean a > slate as possible. > > So, my proposal is that we include a section in the Reference that > details the deprecated vocabulary from the original schema, but that > we do *not* include the deprecated properties in the RDF schema. > > This does have the effect that there will be vocabulary elements in > the SKOS namespace in use in some legacy vocabularies that are not > explicitly defined in the RDF schema. There is a question as to > whether we consider this to be a problem. > > A related question here concerns the namespace of the SKOS vocabulary. > I think there is an implicit assumption that we will continue to use > the http://www.w3.org/2004/02/skos/core namespace for the vocabulary. > I see no strong argument for changing this (and arguments for not > changing it -- for example to ensure that existing SKOS content and > applications continue to work), but thought that it would be useful > to at least have this explicitly stated. It seems from the discussions on yesterday's telecon that these issues are closely related. Hopefully the following summarises possible courses of action: *A*/ Keep the existing SKOS namespace and do not include definitions of the old vocabulary. Reference should include an appendix describing the deprecated vocabulary. Pros: + Existing legacy data can continue to use vocabulary Cons: - Deprecated vocabulary lacks machine readable descriptions. - Semantics of the SKOS vocabulary may change (e.g. broader), causing problems with legacy applications. *B*/ Keep the existing SKOS namespace, and include the old vocabulary in the schema, marked as deprecated. Pros: + All vocabulary in use has machine readable descriptions. + Existing legacy data can continue to use vocabulary Cons: - Potential "bloat" in the schema. - Not quite a "truth and beauty" solution, with the first "official" version of the schema containing deprecated vocabulary - Semantics of the SKOS vocabulary change (e.g. broader), causing problems with legacy applications/collections. *C*/ Introduce a new SKOS namespace, without the old vocabulary. Existing schema remains. Pros: + We can provide new semantics without implicitly affecting existing collections or implementations + Clear versioning + Old vocabulary still has machine readable descriptions Cons: - Legacy collections may need to update. Following the discussion, my preference (in decreasing order) is C, A, B, but then I'm a truth and beauty kind of guy :)-) Sean -- Sean Bechhofer School of Computer Science University of Manchester sean.bechhofer@manchester.ac.uk http://www.cs.manchester.ac.uk/people/bechhofer
Received on Wednesday, 9 April 2008 12:13:19 UTC