daniel added a comment. In https://phabricator.wikimedia.org/T93207#1133747, @mkroetzsch wrote:
> @daniel: Have you wondered why XML Schema decided against changing their > URIs? It is by far the most disruptive thing that you could possibly do. Besides a breaking change in the interpretation, the meaning of a URI. > Ontologies don't work like software libraries where you download a new > version and build your tool against it, changing identifiers as required. > Changing all URIs of an ontology (even if only on a major version increment) > will break third-party applications and established usage patterns in a > single step. There is no mechanism in place to do this smoothly. If you make a breaking change to the data model, third-party applications will break anyway when they try to consume the data. Better give them a way to tell. > You never want to do this. Even changing a single URI can be very costly, and > is probably not what you want if the breaking change affects only a > diminishing part of your users (How many BCE dates are there in XSD files? > How many of those were already assuming the ISO reading anyway?). If the affected group is //very// small, maybe. As to the ISO reading: in ISO 8601:1998, -1 is 1 BCE. in ISO 8601:2004, -1 is 2 BCE, see https://en.wikipedia.org/wiki/0_%28year%29#ISO_8601. And who is using the old interpretation anyway? Well, the Java standard libraries for example, at least according to the docs: https://docs.oracle.com/javase/1.5.0/docs/api/javax/xml/datatype/XMLGregorianCalendar.html says it's 1.0. That's also what BlazeGraph uses. Sure, there will be a lot less negative dates out there than positive. But this change //broke all of them// without //any// way to know which interpretation is intended when you see an xsd:date in a document. So, which spec should we use for generating our output, xsd 1.0 / ISO 8601:1998 or xsd 1.1 / ISO 8601:2004? > Having a version number in URLs does not solve the problem of versioning: it > just creates an obligation for you to change *all* URIs whenever you update > the ontology. Well, you change the base URI, yea. > If you really ever want to make a breaking change to one URI, then you just > create a new URI for this purpose and keep the old one defined as it was. > Then you stop using the old one in the data. Clean, easy, and usually > without any disruption to 99% of the users (depending on which URI you > changed of course ;-). That's exactly what having a version number in the URI does. I would have preferred if XSD had just introduced a new data type, xsd:astroDate or something. That would have avoided the breaking change. > This introduction of new names is completely independent of your ontology > document version. Now I'm confused. To me the introduction of new names //is// the new ontology version. > Besides all this, breaking changes are extremely rare. The example you gave > (changing the meaning of an XML Schema datatype) does not apply to us, since > we cannot do such things in our ontology. We don't? We may very well define our own data type for dates, since even for the gregorian calendar model, xsd:date doesn't cover all our needs. > In essence, our ontology is just a declaration of technical vocabulary. Most > changes you could make do not cause any incompatibility -- the Semantic Web > is built on an open-world assumption so that additions of information to the > ontology never are breaking anything. > The only potentially breaking change to an ontology is when you delete some > information, but even there it is hard to see how it should break a specific > application. Well, you can introduce a contradiction, that would "break" the ontology internally. But worse, you can change the //interpretation// of the terms in the ontology, which will break //applications//, if produce and consumer of the data do not agree on the interpretation. > Summing up, the only breaking change to an ontology is to change an important > URI that many people rely on. The current proposal is to introduce a > mechanism for doing exactly this. There is two dicussions here: 1. change the ontology URI to reflect the fact that it is a wikibase ontology, not a wikidata ontology. 2. include a version number in the ontology uri. This ticket is about (1). Your arguments seem to be concerned mostly with (2), perhaps we should have a separate ticket for that. Do I understand you correctly that you agree that we //should// change the base URI to refer to wikibase, and do it very soon? TASK DETAIL https://phabricator.wikimedia.org/T93207 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: adrianheine, Manybubbles, Smalyshev, mkroetzsch, Denny, Lydia_Pintscher, Aklapper, daniel, Wikidata-bugs, aude, Krenair, Dzahn _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
