Page MenuHomePhabricator

Add flavor=basicdump
Closed, DeclinedPublic



I am testing the entities' dumps via Special:EntityData.
And I have two big problems.

First problem, I saw the concepts of GeoSPARQL in the dumps of entities. It's fun but almost no databases support GeoSparql and sometimes, this causes bugs.
Example RDF with Geosparql (POINT) :

So... I tested BlazeGraph in the aim to support GeoSparql. For the moment, I can not deploy it in production (again a lot problems). It's my second problem : "I can not use your experimental database"

Conclusion : I can not use RDF of Wikidata for the moment because I can not import your dump in my old triplestores and I can not use Blazegraph for the moment.

Question : can you add an export without experimental tools/types ?
For example : "ttl" of flavor "basicdump" : Special:EntityData/QXXXX.ttl?flavor=basicdump

I think the perfect RDF is the enemy of good RDF database. A basic dump without GeoSparql is already a very good work and it will be compatible with the majority of RDF databases. When it will be ok, I will open quickly a SPARQL endpoint of Wikidata.


Event Timeline

Karima created this task.Jun 30 2015, 2:33 PM
Karima assigned this task to Smalyshev.
Karima raised the priority of this task from to Normal.
Karima updated the task description. (Show Details)
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 30 2015, 2:33 PM

Please do not overuse/misuse the Epic tag.

Do you have a link to the patch for review?

Ciencia_Al_Poder set Security to None.
Ciencia_Al_Poder removed a subscriber: Ciencia_Al_Poder.
Bugreporter added a subscriber: Bugreporter.

Clean up the task using "Create Subtask" function.

Sorry, I'm a newbie
@Ciencia_Al_Poder what patch ?
@Bugreporter You want I create a subtask of this task with the title "Clean up the task" ?

Ok, I think I now see what happened here:

So basically you created this task with the "create subtask" but you didn't remove any of the CC or projects of the original task

Sorry, I'm a newbie
@Ciencia_Al_Poder what patch ?

The task had the Patch-For-Review tag, whis should be included only when there's a patch for review. It doesn't apply here and it was copied over from the original task.

@Bugreporter You want I create a subtask of this task with the title "Clean up the task" ?

No. Bugreporter said he was "cleaning up the task", which is now done :)

The dump of looks fine and the database should accept any triples of any type, even if no special handling for them is available. I'm not sure what the point of changing the types or removing GeoSPARQL would be. Which triple store exactly can not handle these types and what exactly is the problem there?

the database should accept any triples of any type

Yes, the database should accept any triples in theory but for example, GeoSparql can create bugs because the implementation is not finished. No database has finished the implementation of geosparql (or maybe only Oracle).
Example with Virtuoso :

I searched unit tests of GeoSparql for my benchmark of databases ( ). I didn't found.

Geosparql is a new tool and the implementation is not finished. The SPARQL endpoints of Wikidata have need stability and robustness. I think.

@Karima what you referred to is an example of an edge case in a different format, so I'm not sure how it applies to our case. If there are specific problems in the RDF data as we produce it - such as incompatibility with any of the major and commonly used triple store - I would be glad to hear about it and look for solutions. If not, then I'm not sure what the problem is.

I can test incompatibility of types with the triple stores on the market, if you want help all the editors to be compatible with Geosparql. But a quick solution is to create a filter of your side and hide these exotic triples for basic developer (like me) so I will deploy easily an core Wikidata and share compatible queries with the community.

If wikidata can not be give a core of data (with basic/stable types), each RDF database of Wikidata will have different behaviours, ie the same query SPARQL will not give the same result in function of the endpoint. For an enduser, it will be incomprehensible. We have to have the same results in the mirrors of Wikidata.

I can develop a filter for removing these exotic data but If I do that... the developers like me will do the same thing but with another manner (rename the type or remove triples with geoPOINT and add 2 triples latitude/longitude, etc) and we will have, in one year, 100 different versions of "mirror" Wikidata in function of the version of databases. I think, it's not the idea of Wikidata.

For me, it's not a problem of triplestore. It's a problem of interoperability of Wikidata. We need in the future a process before to impose a new datatype.
Today it's geosparql and tomorrow, it will be "coolgeosparql" (And I will have to buy the last version of the last cool database... or wait two years, the patch in a free robust version for reusing my data in Wikidata). There is a problem...

So, do I have to develop my own version of Wikidata ? or Wikidata can propose an interoperable subversion for avoid this inevitable disorder...

Smalyshev added a comment.EditedJun 30 2015, 6:28 PM

I'm sorry, but I still not sure solution to which problem you are seeking. GeoSPARQL is a standard to represent coordinate data. If you don't like it, you can use the component items as described in Besides that, I'm not sure what exactly you're looking for.

Karima added a comment.EditedJul 1 2015, 7:40 AM

GeoSPARQL is a standard of OGC and not of W3C. Wikidata needs to do the difference between the lobbies and the recommendation of Web. I read in the documentation of this standard of OGC.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

So... the editors don't implement this standard because there are probably patents behind. If the patents are not free, Geosparql will be never a real recommandation of W3C.

Thanks for your example, I didn't see the triples of Globecoordinate without geosparql. It's enough for me and my students.

However, I can not load your ttl without remove the triples in relation with geosparql :-/ My cheap triple store don't like the patents probably.
So do I have to implement a filter of my side or your propose a basic RDF for cheap triple store ?

Smalyshev removed Smalyshev as the assignee of this task.Jul 1 2015, 8:34 AM
Smalyshev removed a subscriber: Smalyshev.
Smalyshev added a subscriber: Smalyshev.

@Karima I can not advise about how to implement your software but really don't see how I can help here since I still don't understand what the problem is.

Karima added a comment.EditedJul 1 2015, 9:13 AM

My problem : I cannot load the ttl of wikidata with a request LOAD when there are triples about GeoSparql :


===> ERROR : database don't support WKT string with the coordinates with type geo:wktLiteral

NB : I tested the 5 examples in the doc of Geosparql on 4 different triple stores... no database supports it for the moment.

@Karima which database you are using? Blazegraph certainly can load the data just fine, and I don't see why any triple store would not be able to load any arbitrary typed literal. You don't need full GeoSPARQL support for that - in fact, you don't need any GeoSPARQL support for it - you just need to be able to load arbitrary typed literals.

There is indeed a bit of a problem specifically with Virtuoso 7.1.0 as it seems to be a bit quirky in loading geo data (see e.g., I'll look into it. It may be a bug that was recently fixed in 7.2.0, see:

Karima closed this task as Declined.Jul 5 2015, 4:01 PM
Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptJul 5 2015, 4:01 PM
Karima added a comment.Jul 5 2015, 4:03 PM

I developed a filter of my side for removing the problems in the ttl.