Re: Deprecate in favour of /ns/rdf# ??

[Checks date in case it is early in April, nope doesn't seem to be.]

Put me down for a strong "bad idea" vote.

At a stroke this would mean that all currently published RDF will be 
using deprecated terms.

For the "transition" then all tools would need to support both sets of 
URIs and provide some form of interoperation across them. All existing 
SPARQL queries that use rdf/rdfs terms would fail on new data, all new 
SPARQL queries would fail on old data. So publishers would have to start 
providing duplicate statements using both URIs, query writers would need 
to write all their queries as unions to handle both worlds.

I put scare quotes round "transistion" because it is not obvious when 
enough of the RDF world might have been republished using the new URIs 
to allow tools providers and query writers to safely drop the deprecated 
versions. So the transition period would likely never end.

Improvements to usage notes and labelling are possible with no change in 
URI so the only presented argument in favour is that the namespace will 
be slightly easier to remember. Given, as noted in the Against case, the 
vast majority of people don't remember URI's anyway (relying on tools, 
or cut/paste) that seems like a trivial benefit.


On 28/11/13 14:27, Phil Archer wrote:
> Dear all,
> An idea has been floated and I'd like to assess the community's
> reaction. The rdf and rdfs namespaces are hard to remember (I always
> copy and paste, I guess you do too), but how do you react to the idea of
> deprecating those namespaces in favour of the much easier to remember
>|s ?
> For emphasis, there would be *no change* at all to the semantics of any
> term, but the existing semantics might be more clearly explained.
> For:
> ====
> 1. In addition to replicating the schemas at that namespace, more
> detailed usage notes could be added;
> 2. Multilingual labels, comments and usage notes could easily be added
> (this is something I'm really keen to promote);
> 3. You'd be able to remember the namespace.
> Against
> =======
> 1. Everyone just copies and pastes and loads of tools have the
> namespaces built in so it's pointless.
> 2. Any copy or derivative work might cause confusion.
> 3. One person's clarity is another person's confusion, meaning that the
> promise of not changing the semantics might be hard to keep in some
> people's minds.
> How it might happen
> ===================
> *IF* there is community desire for this then I would suggest that a
> Community Group be formed to take it on. Any publication of the schema
> in /ns space would have to make clear that the relevant standards remain
> untouched and normative so that if any errors are seen, then the /TR doc
> is the one to choose.
> Good idea?
> Stupid idea?
> Great, count me in for the Community group?
> You are a moron, please don't ever suggest anything like that ever again?
> If your answer is negative then I hereby deny all association :-) I'm
> just making a public version of something said to me in private.
> Thanks
> Phil.

Received on Thursday, 28 November 2013 14:48:56 UTC