Talk:Wikibase/Indexing/RDF Dump Format

I see that pqv: links statements to qualifier value nodes, but it doesn't return anything for item-valued qualifiers [e.g.]. I am using qualifier hashes in Wikibase-cli commands, and I'm having to get the JSON for each statement from the database and extract the qualifier hash from there. In thousands-long batches, those database calls take a lot of extra time; it would help a lot if I could just get the hashes in my sparql query. Thanks!

Indeed, in the RDF representation complex value nodes are meaningful only for values that describe something where extra information is useful (units, calendars). Because other wikidata items can be described unequivocally with their ID they do not need a complex value node attached to them. We do not store them because they don't add any value to the graph and would probably increase the number of triples quite significantly.

My understanding is that qualifier hashes are very much internal to the wikibase entity representation and you should not assume that the RDF model is using them, in fact it does not seem to use them for values (it does for references). So I would strongly suggest not using WDQS to track such low-level information.

Ok, thanks.

I do not see the wdtn prefix used in the Wikidata Query Service. For instance, This gives zero results:

SELECT
  ?s ?o
WHERE {
  ?s wdtn:P5822 ?o .
} 
LIMIT 10

Try it!

Is there something that I am missing?

Looking which properties have a "DirectClaimNormalized" predicate in the query service : https://w.wiki/9fQA it seems only identifier properties have this normalization.

Thanks, I see now.

SELECT 
  ?s ?o
WHERE {
  ?s wdtn:P212 ?o .
}
LIMIT 10

Try it!

Gives a result. I thought that amount properties would use wdtn for SI conversion

The example for quantity contains the prefix v: which I don't see anywhere else, does anyone know what this is supposed to be?

I think this is supposed to be "wdv" for <http://www.wikidata.org/value/>. See for example this query. I have updated the examples accordingly.

The docs here say "Full statement is represented as separate node, with prefix wds:" however a TTL dump shows no "wds:" but only "s:" - So should this documentation be changed? Thanks.

In the query service it seems only the wds: is defined.

https://query.wikidata.org/#select%20%23%28str%28s%3A%29%20as%20%3Fs%29%20%0A%20%20%20%20%20%20%20%28str%28wds%3A%29%20as%20%3Fwds%29%20%0A%7B%7D%20 works fine, but decomenting the first line in the query leads to an error because it’s undefined :

select (str(s:) as ?s) 
       (str(wds:) as ?wds) 
{ }

Try it!

What does the value of wikibase:geoPrecision mean exactly?

A couple years ago I did some research and came up with this:

• "measured in 1/111000 meters (eg street address or building -> 30.8/111000)"

But I can't remember how I came to that conclusion. Is it correct?

cc @Smalyshev (WMF)

Does Wikibase/DataModel#Geographic_locations help?

• Wikibase/DataModel#Geographic locations "representing degrees of distance"

• https://en.wikibooks.org/wiki/SPARQL/WIKIDATA_Precision,_Units_and_Coordinates#Coordinates "measured in degrees. Multiply by 111000 to convert to meters"

• Google "A degree of longitude is about 111 kilometers (69 miles) at its widest. The widest areas of longitude are near the Equator, where the Earth bulges out. Because of the Earth's curvature, the actual distance of a degree depends on its distance from the Equator."

Using degrees is not the best way to measure precision since it depends on location and direction. But it is what we got.

I'll add this to Wikibase/Indexing/RDF Dump Format

Hallo,

the second example box is wrong - Q3 is "life", while the "Universe" is Q1.

I would edit it by myself, but i have no knowledge about the long identifiers starting with `wbs:`

For en example the data doesn't have to be correct, just correctly formatted. Besides if we were to correct it, we would need more things to be fixed. It still contains a reference to P7, which property no longer exists.

based on the existing RDF Dump Format model it isn't possible to match the Media-Info RDF-Dump based on a Wikidata-SPARQL-Query for images using ?item wdt:P18 ?img. The reason is, that the commons media file value stored in the Wikidata Wikibase like http://commons.wikimedia.org/wiki/Special:FilePath/%FileName% but in the media-info rdf-dump this values isn't represented, only the full qualified upload url, which is hard to guess without any other information.

What is prefixed by osmm: osmt: and other osm_: ?

These prefixes can be found everywhere in examples, but they are not listed here.

They are the prefixes from the OpenStreetMap (OSM) Data Model which are necessary for querying the OSM SPARQL Endpoint at https://sophox.org

 "OSM Data":{
      "osmnode":"https://www.openstreetmap.org/node/",
      "osmway":"https://www.openstreetmap.org/way/",
      "osmrel":"https://www.openstreetmap.org/relation/",
      "osmt":"https://wiki.openstreetmap.org/wiki/Key:",
      "osmm":"https://www.openstreetmap.org/meta/",
      "pageviews":"https://dumps.wikimedia.org/other/pageviews/"
 }

All other osm* prefixes are the Sophox prefixes for its Wikibase instance, corresponding to the same concepts of Wikidata that start with 'w' , e.g.

PREFIX osmd: <http://wiki.openstreetmap.org/entity/>

analog to

PREFIX wd: <http://www.wikidata.org/entity/>"

Same for all of the other prefixes like

PREFIX osmdt: <http://wiki.openstreetmap.org/prop/direct/>

etc. I hope this helps.

Cheers Frog23

According to the site this query should result true:

ASK { wd:Q2 a wikibase:Item }

But it results in false. It this a bug? Is there any other way to check is a entity is an item?

Wikibase/Indexing/RDF Dump Format#WDQS data differences

Thanks, I oversaw this section. Is there any other way to check if an entity is an item (not an property, lemma, etc.) in a query?

It may be unrealiable but I would do ASK { wd:Q2 wikibase:sitelinks [] }.

Disputed interpretation

In an edit at wikidata:Help:Dates Jarekt changed a statements to read "Wikibase software interprets years 1801-1900 with precision 7 as 19th century" and "Wikibase software interprets years 1001-2000 with precision 6 as second millenium". There is discussion on the associated talk page.

I believe Jarekt is referring to the interactive user interface, but I consider it wrong to refer to that interface as "Wikibase software". I believe the RDF API is just as much a part of Wikibase software as the interactive interface. The RDF data model documentation indicates RDF follows ISO 8601 and XSD 1.1 standard. Both of those indicate precisions by truncating the unneeded information. So, for example, for precision 100 years and a year of 1900, it would be truncated to 19 and understood to include any year from 1900 to and including 1999. Jc3s5h (talk) 22:30, 17 July 2018 (UTC)

RDF Dump Format deals with how data is stored not what it means. Current Wikidata standard of interpreting concept of 1st century as years 1-100, second century as years 101-200, etc. and 1st century BC as years 100 BC-1 BC, is perfectly consistent with international understanding of those terms for hundreds of years.See 1st century, etc. If you like to redefine those term than discussion on ''RDF Dump Format'' talk page is not the right place. Wikidata is not consistent with ISO 8601 and XSD 1.1 standards, which is unfortunate but as wikidata:Help:Dates mentioned Wikidata dates are "resembling ISO 8601" but do not follow it. Other difference is how we store BC dates and section d:Help:Dates#Years_BC explains conversions which are done to from the format used by Wikidata to RDF Dump format.

I do not understand your point about of Wikidata GUI not being part of "Wikibase software". I never tried this but I believe that if you create a different instance of wikibase using wikibase software than it comes with the GUI. So I am lost...

When I wrote "I consider it wrong to refer to that interface as "Wikibase software" I meant that the interactive user interface is not the only Wikibase-provide method to read and write data, so that writing as if the meanings implicit in that interface were followed by all intefaces is incorrect. I completely reject the notion that "RDF Dump Format deals with how data is stored not what it means." Explaining what the RDF Dump Format means is the purpose of this page.