Prepare the DraCor Wikidata property
lehkost opened this issue · 15 comments
To stay aligned with a future DraCor property in Wikidata, we should provide an endpoint where Wikidata can check for updates.
The format of this endpoint is described in the "Mix'n'match/Import" article.
We would need at least columns for id, name and q.
It could look like this:
id,name,q
ger000088,Emilia Galotti,Q782653
ita000080,Il servitore di due padroni,Q769831
[…]
@v-ji: Feel free to add if I forgot something. ;)
@lehkost A few questions
- Would this endpoint have to include all plays in the DraCor database or only those that have been associated with a Wikidata ID? The demo sheet has rows without q values.
- What would be a good name for the endpoint?
- The name column would only contain the title of the play, not the author? What about subtitles?
maybe @v-ji is better suited to answer these questions, but i'm happy to join the convo
Would this endpoint have to include all plays in the DraCor database or only those that have been associated with a Wikidata ID? The demo sheet has rows without q values.
Ideally, this endpoint would include all plays in the database. This allows the Mix’n’match service to detect when items are added to Wikidata which already exist in DraCor and suggest adding the relevant property.
What would be a good name for the endpoint?
Because the format is specific to Mix’n’match, I would suggest calling it /mixnmatch or similar.
The name column would only contain the title of the play, not the author? What about subtitles?
The name column is used to match against the Wikidata label, so it should align with common Wikidata practice. From what I can gather, Wikidata bases its naming conventions off of Wikipedia’s for items with an article, and they discourage subtitles unless they’re “a central part of the name of the work”.
Thanks @v-ji for your great input, I agree with all your points.
Just one additional thought. If one day we also enable DraCor perma links for authors, not only works, would we be able to just us the same DraCor Wikidata property? I'm not sure if within the WD property we would have to make a distinction between authors and works.
Because the format is specific to Mix’n’match, I would suggest calling it /mixnmatch or similar.
+1 for mixnmatch
@cmil maybe in the OpenAPI documentation the Wikidata related endpoints could become a group ("wikidata") of their own, like "public", "admin"
Maybe the "hidden" author look-up endpoint could also go there?
If one day we also enable DraCor perma links for authors, not only works, would we be able to just us the same DraCor Wikidata property?
Yes, I think that would be possible with a general DraCor ID property. There are other authority control properties that cover both persons and works, as well. We just have to specify in the proposal what classes may carry this property (e. g. creative works), but I’m sure this can be expanded after the fact.
Because the format is specific to Mix’n’match, I would suggest calling it /mixnmatch or similar.
+1 for mixnmatch@cmil maybe in the OpenAPI documentation the Wikidata related endpoints could become a group ("wikidata") of their own, like "public", "admin"
Maybe the "hidden" author look-up endpoint could also go there?
Another candidate for that group would be /character/{id} ("List plays having a character identified by Wikidata ID").
@cmil maybe in the OpenAPI documentation the Wikidata related endpoints could become a group ("wikidata") of their own, like "public", "admin"
Maybe the "hidden" author look-up endpoint could also go there?Another candidate for that group would be
/character/{id}("List plays having a character identified by Wikidata ID").
The current groups of "public" and "admin" distinguish endpoints depending on whether they need to be authenticated or not. In this sense the new /mixnmatch endpoint would belong to the "public" group. Creating a new group for Wikidata related endpoints would kind of blur the current distinction. Would that group have any practical advantage?
As an alternative we could use a /wikidata prefix for certain endpoint paths. So the new endpoint would be /wikidata/mixnmatch. We could also change /author/{id} into /wikidata/author/{id} to make it clearer where the data comes from. I'm not so sure though about /character/{id} because the data provided by this endpoint is more or less DraCor data, we merely use the Wikidata IDs for identifying authors.
Technically, I think, the groups are "Tags", right? So you can assign multiple tags to an endpoint which would result in making it show up in several of these groupings. IMHO, it would make sense to introduce more of these, e.g. group endpoints that provide the data for Network Analysis,...
@peertrilcke and I also argue in the report that the interactive OpenAPI documentation is the starting point for researchers wanting to use the API and thus is should be structured in a way to provided them with a good overview of what you can do with the API.
The current distinction focuses not so much on what you can do with the API but if you need to be logged in or not. OpenAPI would maybe even provide a machine readable solution to capture the requirement of being logged in or not, see "Security Scheme Object".
For the (still unfinished DTS stuff) I am introducing a DTS Tag to group the three endpoints together:
https://github.com/dracor-org/dracor-api/blob/dts/api.yaml#L1079
I also like the idea of "prefixing" the wikidata endpoints, though.
I'm all for improving the readability of the OpenAPI documentation by giving it a clear structure. Maybe we should think about replacing the "public" tag by one or more tags that better serve this purpose then.
Apart from these more general decisions, trying to unravel this thread, is there anything else to decide before implementing the mixnmatch endpoint as proposed by @v-ji above? I mean, anything that would prevent us from going forward with this?
There is a version on staging now: https://staging.dracor.org/api/wikidata/mixnmatch.