Table range notations are inconsistent across our different data and tools. Let's take T1--0901-T1--0905 for example:
In Cocoda, it is displayed as T1--0901-T1--0905 (I believe this is part of the special handling of DDC notations)
In our JSKOS data, its notation field is T1--0901-0905
In our JSKOS data, its uri field is http://dewey.info/class/1--0901-0905/e23/ (i.e. the notation part itself is 1--0901-0905; note that this is consistent with this paper I have found about DDC URIs)
jskos-tools, given the input notation T1--0901-T1--0905, directly uses it in the URI, i.e. http://dewey.info/class/T1--0901-T1--0905/e23/
As WebDewey uses T1--0901-T1--0905 to display this notation, I believe we should also display it like that. It is unclear to me how the internal JSKOS uri and notation should look like though. It's definitely weird that there are THREE ways to display this range: T1--0901-T1--0905, T1--0901-0905, and 1--0901-0905 (there could also be 1--0901-1--0905, but I haven't seen that anywhere).
Table range notations are inconsistent across our different data and tools. Let's take
T1--0901-T1--0905for example:T1--0901-T1--0905(I believe this is part of the special handling of DDC notations)notationfield isT1--0901-0905urifield ishttp://dewey.info/class/1--0901-0905/e23/(i.e. the notation part itself is1--0901-0905; note that this is consistent with this paper I have found about DDC URIs)T1--0901-T1--0905, directly uses it in the URI, i.e.http://dewey.info/class/T1--0901-T1--0905/e23/As WebDewey uses
T1--0901-T1--0905to display this notation, I believe we should also display it like that. It is unclear to me how the internal JSKOSuriandnotationshould look like though. It's definitely weird that there are THREE ways to display this range:T1--0901-T1--0905,T1--0901-0905, and1--0901-0905(there could also be1--0901-1--0905, but I haven't seen that anywhere).