Christopher added a comment.
Coincidentally, it seems that there are people who know a lot more about this than I do that have debated this issue at length in a long and very informative thread: CRS specification (was: Re: ISA Core Location Vocabulary) <https://lists.w3.org/Archives/Public/public-locadd/2014Jan/0000.html> It is clearly more involved than just using "proper" software libraries and "handling requirements". The conflicting point that I see from your side is that introducing unneeded complexity is bad. And, also, that this was the best practical alternative available for handling "garbage data". Sure, I agree with that, but oversimplification of a problem is worse. I personally feel that the "grunt approach" of using regex in SPARQL to filter URIs from literals in a result set is not clean, and also quite costly. The alternative that introduces subproperties for geometry values is definitely more complex and as indicated in the thread: You need OWL 2 to formally define a complex class and then say that geometry consists of exactly two parts, one that contains the coordinate sequence and another on that contain the CRS. You cannot make such statements using RDFS or OWL. To assert that everything that needs to be said about a geometry value can be put into a standard RDFS string literal is obviously not true. The irregular form of geo:wktLiteral is a kind of "convenience method" that seems to work for most use cases, but definitely not for all, and I really doubt that it is functionally sustainable for complex geodata. TASK DETAIL https://phabricator.wikimedia.org/T129072 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Christopher Cc: daniel, Smalyshev, Christopher, Aklapper, debt, Gehel, D3r1ck01, FloNight, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331 _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
