Ciencia_Al_Poder added a subscriber: Ciencia_Al_Poder.
Ciencia_Al_Poder added a comment.
Please do not overuse/misuse the https://phabricator.wikimedia.org/tag/epic/
tag.
Do you have a link to the patch for review?
TASK DETAIL
https://phabricator.wikimedia.org/T104341
EMAIL PREFERENCES
ht
Bugreporter added a subscriber: Bugreporter.
Bugreporter added a comment.
Clean up the task using "Create Subtask" function.
TASK DETAIL
https://phabricator.wikimedia.org/T104341
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Smalyshev, Bugreporter
Ciencia_Al_Poder added a comment.
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
In https://phabricator.wikimedia.org/T104341#1413944, @Karima wrote:
> Sorry, I'm a newb
Smalyshev added a comment.
The dump of
https://www.wikidata.org/wiki/Special:EntityData/Q1000336.ttl?flavor=dump 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 G
Karima added a comment.
In https://phabricator.wikimedia.org/T104341#1414238, @Smalyshev wrote:
> the database should accept any triples of any type
@Smalyshev
Yes, the database should accept any triples in theory but for example,
GeoSparql can create bugs because the implementation is not fi
Smalyshev added a comment.
@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
Karima added a comment.
@Smalyshev
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
Smalyshev added a comment.
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
https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format#Glob
Karima added a comment.
GeoSPARQL is a standard of OGC and not of W3C. Wikidata need to do the
difference between the lobbies and the recommendation of Web. I read in the
documentation of this standard of OGC.
file:///home/karima/Downloads/11-052r4_OGC_GeoSPARQL_-_A_Geographic_Query_Language_for
Smalyshev added a comment.
@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.
TASK DETAIL
https://phabricator.wikimedia.org/T104341
EMAIL PREFERENCES
https://phabricator.wikimedia.org/se
Karima added a comment.
@Smalyshev
My problem : I cannot load the ttl of wikidata with a request LOAD when there
are triples about GeoSparql :
LOAD http://www.wikidata.org/wiki/Special:EntityData/Q1000336.ttl?flavor=dump
INTO GRAPH http://www.wikidata.org/entity/Q1000336
> ERROR : database do
Smalyshev added a comment.
@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// GeoSPAR
Karima added a comment.
Hello
I developed a filter of my side for removing the problems in the ttl.
Thanks
Bye
karima
TASK DETAIL
https://phabricator.wikimedia.org/T104341
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Karima
Cc: Smalyshev, mkroet
13 matches
Mail list logo
