Re: [Wikidata-tech] Wikidata for cultural heritage?
On 2016-07-01 10:36 AM, Maarten Dammers wrote:
Hi Richard,
I think that persons are probably most mature. All humans have
instance of (P31) human (Q5) and for some subsets (like artists) a lot
properties have a high coverage. Wikidata already connects to a lot of
other sources on the web making it a central node for linked open
data. For painters I keep track of this at
https://www.wikidata.org/wiki/User:Multichill/Paintings_creator_no_authority_control
.
Yes, artists look like a well-served part of the ecosystem.
For events you probably need subclass of event, see
https://tools.wmflabs.org/wikidata-todo/tree.html?lang=en=Q1656682=279
For place geographic location is probably the best one, see
https://tools.wmflabs.org/wikidata-todo/tree.html?lang=en=Q2221906=279
I don't think a subclass is required: if anything the CIDOC-CRM
definition of E5 Event is more abstract than the Wikidata definition of
Q1656682. It's more a case of getting 'isa' (i.e. instance of)
relationships into the data, so that a SPARQL query can know that it is
only dealing with entities of the desired type. What is the Wikidata
procedure/mechanism for doing something like that?
Also take a look at
https://www.wikidata.org/wiki/Wikidata:WikiProject_Visual_arts/Item_structure
. We tried to link to external concepts here.
That's interesting. Has anyone made an attempt to map these properties
to the CIDOC-CRM?
Thanks,
Richard
Maarten
Op 30-6-2016 om 12:07 schreef Richard Light:
Lydia,
Thank you for your responses. I suggest that it would add to the
utility of Wikidata entities if their basic type ('person', 'place',
'event', etc.) was explicitly stated in the RDF.
Best wishes,
Richard
On 2016-06-29 4:56 PM, Lydia Pintscher wrote:
On Sun, Jun 19, 2016 at 1:27 PM, Richard Light
<rich...@light.demon.co.uk> wrote:
Hi,
My view is that, in order for there to be any point in cultural heritage
bodies (museums, libraries, archives, historians) publishing their
collections etc. as Linked Data, there needs to be a common Linked Data
framework representing the historical space-time universe, which they can
all quote. Current practice (such as the British Museum Linked Data
offering) suggests that concepts such as people, places and events will
otherwise be represented either by useless string values or by
system-specific URLs which have no wider meaning.
As a result, I would like to explore the potential for Wikidata to act as
this lingua franca for the cultural heritage community.
You'll see from my earlier messages to this list that I have been grappling
with the SPARQL end-point. Initially I was confused by the interactive
version of the Query Service [1], which differs in its response format from
the similarly-URLed end-point and doesn't provide an RDF/XML response. I
have now managed to set up Wikidata as a 'web termlist' service for artists,
within the Modes software (see attached screenshot). (The data in the pop-up
window is generated on the fly from the Wikidata RDF.)
At this point, I have the following questions:
1. what level of stability is planned as regards Wikidata identifiers/URLs?
Can I treat the full URL (e.g.[3]) as persistent, or can I only rely on the
core Wikidata identifier (e.g. [4]) remaining unchanged into the indefinite
future? (Can I even rely on that?)
Wikidata's IDs are supposed to be stable.
2. what is the policy on inclusivity? Do entities need to be 'notable' in
some sense to be accepted into Wikidata? (I'm imagining a research body
wanting to offer very precise place or event data, or someone with the
ambition to include in Wikidata details of any person who ever lived.)
https://www.wikidata.org/wiki/Wikidata:Notability
3. is there a template for each entity type (e.g. person, place, event)
which guarantees that a query for certain properties will at least identify
entities of the desired type? (My artist termlist query includes a test '$s
ps:P31 wd:Q5' which picks out humans: I'm not clear how I would do the same
for events or places.)
No that does not exist.
Cheers
Lydia
--
*Richard Light*
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
--
*Richard Light*
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Re: [Wikidata-tech] RDF/XML response from SPARQL query?
Hi,
To answer my own question (in case someone else has the same challenge
in future): the Wikidata SPARQL end-point is also available at the very
similar URL:
https://query.wikidata.org/sparql?query={SPARQL}
and this version does return RDF/XML. This is all nicely documented in
the Wikidata documentation [1].
Richard
[1] https://www.mediawiki.org/wiki/Wikidata_query_service/User_Manual
On 2016-06-02 6:33 PM, Richard Light wrote:
Hi,
I have just been exercising the SPARQL end-point [1], and have
successfully retrieved birth and death details for artists mentioned
in the ODNB. That is great, and I am really pleased about it.
However, I would ideally like my CONSTRUCT statement to produce a
machine-processible result, and for me that would mean RDF/XML. Is
there an argument I can add to the URL below which would have the
effect of returning a RDF/XML response?
Thanks,
Richard
[1]
https://query.wikidata.org/#PREFIX%20wd%3A%20%3Chttp%3A%2F%2Fwww.wikidata.org%2Fentity%2F%3E%0APREFIX%20ps%3A%20%3Chttp%3A%2F%2Fwww.wikidata.org%2Fprop%2Fstatement%2F%3E%0APREFIX%20skos%3A%20%3Chttp%3A%2F%2Fwww.w3.org%2F2004%2F02%2Fskos%2Fcore%23%3E%0APREFIX%20p%3A%20%3Chttp%3A%2F%2Fwww.wikidata.org%2Fprop%2F%3E%0Aconstruct%20{%20%3Fs%20%20rdfs%3Alabel%20%3Fname%3B%20p%3AP19%20%3Fpob%3B%20p%3AP20%20%3Fpod%3B%20p%3AP569%20%3Fdob%3B%20p%3AP570%20%3Fdod%20.%20}%20where%20{%20%0A%20%20%3Fs%20p%3AP106%20%3Fo%20.%0A%20%20%3Fo%20%3Fx%20wd%3AQ483501%20.%0A%20%20%3Fs%20rdfs%3Alabel%20%3Fname%20.%0A%20%20%3Fs%20p%3AP1343%20%3Fodnbs%20.%0A%20%20%3Fodnbs%20ps%3AP1343%20wd%3AQ15987216%20.%0A%20%20%0A%20%20FILTER%20%28%20%20lang%28%3Fname%29%20%3D%20%22en%22%20%29%0A%0A%20%20OPTIONAL%20{%20%24s%20p%3AP19%20%3Fpobs%20.%20%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Fpobs%20ps%3AP19%20%3Fpobs2%20.%0A%20%20%20%20%20%20%20%20%20%20%20%20%3Fpobs2%20rdfs%3Alabel%20%3Fpob%20.%0A%20%20%20%20%20%20%20%20%20%20%20%20FILTER%20%28%20lang%28%3Fpob%29%20%3D%20%22en%22%20%29%0A}%0A%20%20%20%20%20OPTIONAL%20{%20%24s%20p%3AP569%20%3Fdobs%20.%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Fdobs%20ps%3AP569%20%3Fdob%20.%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20}%0A%20%20OPTIONAL%20{%20%24s%20p%3AP20%20%3Fpods%20.%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%3Fpods%20ps%3AP20%20%3Fpods2%20.%0A%20%20%20%20%20%20%20%20%20%20%20%20%3Fpods2%20rdfs%3Alabel%20%3Fpod%20.%0A%20%20%20%20%20%20%20%20%20%20%20%20FILTER%20%28%20lang%28%3Fpod%29%20%3D%20%22en%22%20%29%0A}%0A%20%20OPTIONAL%20{%20%24s%20p%3AP570%20%3Fdods%20.%0A%20%20%20%20%20%20%20%20%20%20%20%3Fdods%20ps%3AP570%20%3Fdod%20.%20}%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20}%20limit%205%0A
--
*Richard Light*
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
--
*Richard Light*
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Re: [Wikidata-tech] URL strategy
Hi,
To respond (partially) to my own question: SPARQL does do the job for
me, e.g.:
select distinct ?person where {?person ?p ?prop .
?prop ps:P31 wd:Q5 .
} limit 100
returns a list of person URLs. So I'm happy. However, I am still
intrigued as to the logic behind the redirection of the statement URL to
the URL for the person about whom the statement is being made.
Thanks,
Richard
On 2016-06-13 10:51 AM, Richard Light wrote:
Hi,
I'm trying to get to grips with using Wikidata as a Linked Data
resource, and would welcome some guidance.
Using the SPARQL end-point [1], I submit a query which looks for people:
PREFIX ps: <http://www.wikidata.org/prop/statement/>
PREFIX wd: <http://www.wikidata.org/entity/>
describe ?s where {?s ps:P31 wd:Q5 .
} limit 100
The results give a set of wd:statement URLs (e.g. [2]), each of which
has the required 'P31 Q5' property and four others (wikibase:rank,
rdf:type and a couple of 'derived from' properties). So this looks
like a simple statement, which is in some sense a property of the
person I am looking for. I would then expect to refine my SPARQL
query to pick up the person about whom this statement was made, and
thereby get access to their other properties.
However, when I dereference the statement URL, I find that I have
magically arrived at the URL of the person themselves [3].
While this is all very clever, it leaves me at a loss as to how I can
access the properties of the person using SPARQL.
Thanks,
Richard
[1] https://query.wikidata.org/
[2]
http://www.wikidata.org/entity/statement/q23-935f9100-47ca-f387-7946-45f9db09e81f
[3] https://www.wikidata.org/wiki/Q23 when accessed through the
browser, or https://www.wikidata.org/wiki/Special:EntityData/q23 when
accessed through curl with a suitable Accept header
--
*Richard Light*
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
--
*Richard Light*
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
[Wikidata-tech] URL strategy
Hi,
I'm trying to get to grips with using Wikidata as a Linked Data
resource, and would welcome some guidance.
Using the SPARQL end-point [1], I submit a query which looks for people:
PREFIX ps: <http://www.wikidata.org/prop/statement/>
PREFIX wd: <http://www.wikidata.org/entity/>
describe ?s where {?s ps:P31 wd:Q5 .
} limit 100
The results give a set of wd:statement URLs (e.g. [2]), each of which
has the required 'P31 Q5' property and four others (wikibase:rank,
rdf:type and a couple of 'derived from' properties). So this looks like
a simple statement, which is in some sense a property of the person I am
looking for. I would then expect to refine my SPARQL query to pick up
the person about whom this statement was made, and thereby get access to
their other properties.
However, when I dereference the statement URL, I find that I have
magically arrived at the URL of the person themselves [3].
While this is all very clever, it leaves me at a loss as to how I can
access the properties of the person using SPARQL.
Thanks,
Richard
[1] https://query.wikidata.org/
[2]
http://www.wikidata.org/entity/statement/q23-935f9100-47ca-f387-7946-45f9db09e81f
[3] https://www.wikidata.org/wiki/Q23 when accessed through the browser,
or https://www.wikidata.org/wiki/Special:EntityData/q23 when accessed
through curl with a suitable Accept header
--
*Richard Light*
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
[Wikidata-tech] RDF/XML response from SPARQL query?
Hi,
I have just been exercising the SPARQL end-point [1], and have
successfully retrieved birth and death details for artists mentioned in
the ODNB. That is great, and I am really pleased about it. However, I
would ideally like my CONSTRUCT statement to produce a
machine-processible result, and for me that would mean RDF/XML. Is
there an argument I can add to the URL below which would have the effect
of returning a RDF/XML response?
Thanks,
Richard
[1]
https://query.wikidata.org/#PREFIX%20wd%3A%20%3Chttp%3A%2F%2Fwww.wikidata.org%2Fentity%2F%3E%0APREFIX%20ps%3A%20%3Chttp%3A%2F%2Fwww.wikidata.org%2Fprop%2Fstatement%2F%3E%0APREFIX%20skos%3A%20%3Chttp%3A%2F%2Fwww.w3.org%2F2004%2F02%2Fskos%2Fcore%23%3E%0APREFIX%20p%3A%20%3Chttp%3A%2F%2Fwww.wikidata.org%2Fprop%2F%3E%0Aconstruct%20{%20%3Fs%20%20rdfs%3Alabel%20%3Fname%3B%20p%3AP19%20%3Fpob%3B%20p%3AP20%20%3Fpod%3B%20p%3AP569%20%3Fdob%3B%20p%3AP570%20%3Fdod%20.%20}%20where%20{%20%0A%20%20%3Fs%20p%3AP106%20%3Fo%20.%0A%20%20%3Fo%20%3Fx%20wd%3AQ483501%20.%0A%20%20%3Fs%20rdfs%3Alabel%20%3Fname%20.%0A%20%20%3Fs%20p%3AP1343%20%3Fodnbs%20.%0A%20%20%3Fodnbs%20ps%3AP1343%20wd%3AQ15987216%20.%0A%20%20%0A%20%20FILTER%20%28%20%20lang%28%3Fname%29%20%3D%20%22en%22%20%29%0A%0A%20%20OPTIONAL%20{%20%24s%20p%3AP19%20%3Fpobs%20.%20%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Fpobs%20ps%3AP19%20%3Fpobs2%20.%0A%20%20%20%20%20%20%20%20%20%20%20%20%3Fpobs2%20rdfs%3Alabel%20%3Fpob%20.%0A%20%20%20%20%20%20%20%20%20%20%20%20FILTER%20%28%20lang%28%3Fpob%29%20%3D%20%22en%22%20%29%0A}%0A%20%20%20%20%20OPTIONAL%20{%20%24s%20p%3AP569%20%3Fdobs%20.%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3Fdobs%20ps%3AP569%20%3Fdob%20.%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20}%0A%20%20OPTIONAL%20{%20%24s%20p%3AP20%20%3Fpods%20.%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%3Fpods%20ps%3AP20%20%3Fpods2%20.%0A%20%20%20%20%20%20%20%20%20%20%20%20%3Fpods2%20rdfs%3Alabel%20%3Fpod%20.%0A%20%20%20%20%20%20%20%20%20%20%20%20FILTER%20%28%20lang%28%3Fpod%29%20%3D%20%22en%22%20%29%0A}%0A%20%20OPTIONAL%20{%20%24s%20p%3AP570%20%3Fdods%20.%0A%20%20%20%20%20%20%20%20%20%20%20%3Fdods%20ps%3AP570%20%3Fdod%20.%20}%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20}%20limit%205%0A
--
*Richard Light*
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Re: [Wikidata-tech] how is the datetime value with precision of one year stored
On 01/09/2015 09:26, Markus Krötzsch wrote: On 01.09.2015 05:17, Stas Malyshev wrote: Hi! I would have thought that the correct approach would be to encode these values as gYear, and just record the four-digit year. While we do have a ticket for that (https://phabricator.wikimedia.org/T92009) it's not that simple since many triple stores consider dateTime and gYear to be completely different types and as such some queries between them would not work. I agree. Our original RDF exports in Wikidata Toolkit are still using gYear, but I am not sure that this is a practical approach. In particular, this does not solve the encoding of time precisions in RDF. It only introduces some special cases for year (and also for month and day), but it cannot be used to encode decades, centuries, etc. My current view is that it would be better to encode the actual time point with maximal precision, and to keep the Wikidata precision information independently. This applies to the full encoding of time values (where you have a way to give the precision as a separate value). For the simple encoding, where the task is to encode a Wikidata time in a single RDF literal, things like gYear would make sense. At least full precision times (with time of day!) would be rather misleading there. In any case, when using full precision times for cases with limited precision, it would be good to create a time point for RDF based on a uniform rule. Easiest option that requires no calendar support: use the earliest second that is within the given interval. So "20th century" would always lead to the time point "1900-01-01T00:00:00". If this is not done, it will be very hard to query for all uses of "20th century" in the data. This is an issue which the cultural heritage community has been dealing with for decades (:-) ). In short, a single date is never going to do an adequate job of representing (a) a period over which an event happened and (b) uncertainty over the start and/or end point in this period. These periods will almost never neatly fit into years, decades, centuries, etc.: these are just a convenience for grouping approximations together. Representing e.g. '3.1783 - 12.1820' as either decades or centuries is going to give a very misleading version of what you actually know about the period (and you still can't reduce it to a single 'date thing'). I think that you need at least two dates to represent historical event dating with any sort of honesty and flexibility. What those dates should be is a matter for discussion: the CIDOC CRM for example has the concept of "ongoing throughout" and "at some time within", which are respectively the minimal and maximal periods associated with an event. Common museum practice in the U.K. is to record 'start date' and 'end date', each with a possible qualification as regards its precision. Richard Markus ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech -- *Richard Light* ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Re: [Wikidata-tech] how is the datetime value with precision of one year stored
Raul, How do you get to these 'fine grain values'? They are not in the HTML rendition at the URLs you quote, and when I go to the RDF for these concepts I don't see any date information. Is this a Wikidata secret? I would have thought that the correct approach would be to encode these values as gYear, and just record the four-digit year. Richard On 31/08/2015 18:19, Raul Kern wrote: Hi, how is the datetime value with precision of one year stored? For example for birt date in https://www.wikidata.org/wiki/Q299687 fine grain value for "1700" is "1.01.1700" But for population date field in https://www.wikidata.org/wiki/Q216 the fine grain value for "2014" is "30.11.2013" Which is kind of unexpected. -- Raul ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech -- *Richard Light* ___ Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Re: [Wikidata-tech] Content negotiation
Bene,
Thanks for this. Yes, that works.
For SELECT queries, the response format is
application/sparql-results+xml by default (even without specifying the
format parameter), and the only other format I could persuade it to
offer was JSON (with format=json).
For CONSTRUCT queries (the useful sort :-) ), you need format=rdf (or
format=application/rdf+xml), which returns a lovely RDF XML document.
If you omit the format parameter, you get a 'File not found' error.
If you put format=json, you do get a JSON response, but (a) the file
type isn't specified: the response filename is just the generic
'sparql', and (b) the JSON that is returned looks a bit reified to me.
Others can comment on whether this is what they would expect from
serializing the results of a CONSTRUCT query in JSON. [1]
Richard
[1]
http://wdqs-beta.wmflabs.org/bigdata/namespace/wdq/sparql?query=prefix%20wdt:%20%3Chttp://www.wikidata.org/prop/direct/%3Eprefix%20wd:%20%3Chttp://www.wikidata.org/entity/%3E%20CONSTRUCT%20{?h%20wdt:P734%20?name%20.}%20WHERE%20{%20?h%20wdt:P31%20wd:Q5%20.?h%20wdt:P734%20?name%20.?name%20rdfs:label%20%22Light%22@en}%20LIMIT%20100format=json
On 27/08/2015 08:24, Bene* wrote:
Hi Richard,
I can only answer the last part of your question but you can access
the SPARQL endpoint directly under
wdqs-beta.wmflabs.org/bigdata/namespace/wdq/sparql?query= and I think
you can also add a format parameter to specify in which format the
result should be returned.
Best regards
Bene
Am 27.08.2015 um 09:20 schrieb Richard Light:
Hi,
I am doing some 'kicking the tyres' tests on Wikidata as Linked
Data. I like the SPARQL end-point, which is more helpful than most,
and successfully managed a query for people with the surname Light
last night. (Only five of them in the world, apparently, but that's
another matter. :-) )
What I do have an issue with is the content negotiation. I kept
failing to get an RDF rendition of my results, and as a last resort I
read the documentation [1].
This described a postfix pattern which delivers RDF XML (e.g. [2]).
However, this pattern is itself subject to content negotiation, and
an initial 303 response converts the URL to e.g. [3]. I am
interested in knowing what pattern of URL will deliver RDF/XML
/without /requiring content negotiation, and the answer to that
question is not [2] but [3]. This matters, for example, in scenarios
where one wants to use XSLT's document() function to retrieve an RDF
XML response directly. The URL pattern [2] will fail. So the
documentation is currently unhelpful.
In a similar vein, is there a syntax for running a SPARQL query on
Wikidata such that the response is delivered as RDF XML? In many
end-points there is a parameter you can add to specify the response
format, which allows you to submit searches as HTTP requests and
include the results directly in your (in my case XML-based)
processing chain. An HTML results page isn't very machine-processible!
Thanks,
Richard
[1] https://www.wikidata.org/wiki/Wikidata:Data_access
[2] https://www.wikidata.org/entity/Q3807415.rdf
[3] https://www.wikidata.org/wiki/Special:EntityData/Q3807415.rdf
--
*Richard Light*
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
--
*Richard Light*
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
