It’s a standard value in a property, with the datatype “uri”.
Thanks for your feedback: I added URIs to Wikipedia and Commons in the description of some sample items.
Can you suggest additional examples of access to Wikidata as information service, in order to have a better understanding of such feature?
All Omeka items are available as data : https://p-lod.umasscreate.net/api/items?id=1488 for the example above. Wikipedia works the same, like any semantic service in fact. You can query the data on wikipedia and display them as you want, see https://query.wikidata.org.
Thanks for your feedback.
Let’s take as example my item Madonna of Fossa.
The date of creation is the Property P571 of the Wikidata element Q17636011: see Wikidata Query Service.
I can edit manually the field dcterms:date including the value “1340”: is it possible to fill that field directly with the result of a Wikidata query?
There is no easy to way to do that out of the box, but it would totally be doable by developing a dedicated module. Based on your example, it’s easy to crate the following url :
if you open it, you will see that the requested data (1340) is there, you would only need your module to decide how to extract it / format it / store it.
Symac, thank you for your reply.
In the example we are discussing about, the module you are suggesting should substitute the standard item displaying module: have you any demo (even not using Wikidata) to suggest in order to have a better understanding about how to proceed?
Hi Pietro. In my suggestion, I was thinking about a module that would work in backoffice and would fill the dcterms:date for example. The default display would then be used.
If you want to dynamically query wikidata on the frontend side, that should also be done using some kind of Javacript. There are libraries like qLabel that do it for the labels, I can’t think of any reasons why it couldn’t be done for specific properties.
So to summarize: all of these should be done, it’s just a matter of coding time needed!
coding skills apart, the main proplem on my side is to understand how Omeka-s deals with linked open data: adding an URI in a static value (potentially unupdated) for a property seems to me a little bit reductive. More appropriate could be dynamically querying wikidata on the frontend side, as you suggest, but it seems strange that this requires additional coding.
Sorry for so basic questions, but I’m still trying to understand the right approach to use this platform.
The CHNM team might be able to answer more precisely than me but from my point of view, right now, omeka-s offers a propery way to store data in a correct way by setting URI or values but is not doing much on the front end side, that’s why I am speaking about developing some module to override the default behaviour.
But I am pretty sure in the future some enhancements regarding the possibilities offered by linked data will join the core version of Omeka-S.