Jmvanel added a comment.
We are 1,5 year after the original query.
This is probably a few lines to change.
I wonder what prevents to do it.
This will make Wikidata much more discoverable for Semantic Web tools.
TASK DETAIL
https://phabricator.wikimedia.org/T203400
EMAIL PREFERENCES
Jmvanel added a comment.
Sure, the action planned will make a progress, when this happens ...
But from a RDF point of view the mapping from Wikibase to RDF is not satisfying.
Wikibase can have the complexity that it needs for its purposes, but RDF is about simplicity, and unique stable URI's
Jmvanel added a comment.
I checked that there is no problem regarding the coherence of the database is between what SPARQL outputs and what entity URI's output.
Consider this simple query:
PREFIX wikidata:
SELECT * WHERE {
wikidata:Q625994 ?pred ?obj .
}
Run it in YasGUI (generic tool)
Jmvanel added a comment.
I can pretty much understand that Wikibase has several URI's for the same property (or closely related ones) .
Wikibase is a special purpose database on its own, but regarding the RDF view offered by BlazeGraph server, there is indeed a problem regarding the coheren
Jmvanel added a comment.
We are 3 months later , and nothing happened.
For RDF users , this is really blocking.
Not only does it cause generic tools to display badly WKD RDF , example here Q625994 the "conference" entity :
http://semantic-forms.cc:1952/display?displayuri=
Jmvanel added a comment.
The proposed changed is a useful workaround;
but in principle, the RDF data retrieved by content negotiation from an entity URI should bear the reference property URI's not secondary ones.
In by the way, no other RDF dataset I know of has several URI's fo
Jmvanel added a comment.
Is there is a test instance where the latest developments are applied ?
Is the FIX expected to take long ?
NOTE: I'll be testing that the properties' label appear in my generic RDF tool :
http://semantic-forms.cc:9112/search?q=http%3A%2F%2Fwww.wikidata.or
