daniel added a comment. @mkroetzsch: You say that changing the URIs does not solve the problem of breaking changes to an ontology. If I understand you correctly, you are saying that if I run a SPARQL query using the base URI http://acme.com/onto1, but the triple store now uses http://acme.com/onto2, I would get the wrong results without warning. While I agree that this is technically correct, I disagree with the conclusion.
You are right that I would not get an explicit error message like I would when trying to use a now undefined class name in a programming language. I would most likely simply get no result. That's however still better than getting a *wrong* result for a query using http://acme.com/onto1, because the ontology's definition changed, and so my code's assumptions about it are now wrong. Also, when combining information using http://acme.com/onto1 and http://acme.com/onto2 from different sources in the same triple store, no contradictions arise, the structures can coexist nicely. If however I have info using old style http://acme.com/onto1, and another using new style http://acme.com/onto1, and mix them, I may very well get contradictions or other kinds of breakage, due to the changes to the ontology. Finally, consider clients that use RDF data not via SPARQL, but directly as linked data. If they request RDF expecting URIs based on http://acme.com/onto1, but would get URIs based on http://acme.com/onto2, they would very quickly realize, investigate, and adapt. If they however would get http://acme.com/onto1 URIs with slightly modified meaning or structure, that will introduce hard to find bugs, and may lead to data corruption. Am I missing a point somewhere? 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
