Re: Deprecate http://www.w3.org/1999/02/22-rdf-syntax-ns# in favour of /ns/rdf# ??

Hi Phil,

My first reaction is: please, don't.

These are probably the oldest namespaces around. They will stick around 
for a while, if not forever. That would mean that most application stack 
would have to handle both namespaces at different levels. Then just 
think about all the documentation that exists that would need to be 
rewritten, and think about the additional confusion of having updated, 
and un-updated documentation. Datasets would need to be updated, 
re-indexed around the world to accommodate such a change. The thing is 
that most won't do it, which means that we would endup with two 
equivalent URIs for all the RDF & RDFS properties and classes.

Seems to be a big burden to not copy/paste namespaces :)


You 3 "against" points a right, and the cost of doing this is too high 
for the little benefits I see. One thing I know is that none of our 
clients won't pay for doing such a change, and so, we would end-up with 
two problems and add even more confusion.


That is my initial reaction to this suggestion.

Thanks,

Fred

>
> 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 http://www.w3.org/ns/rdf|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:41:44 UTC