John,
Yes, it is related as both could be useful for tagging Commons images. (Acanthostichus hispaniolicus SMNSDO5205-1 01.jpg https://commons.wikimedia.org/wiki/File:Acanthostichus_hispaniolicus_SMNSDO5205-1_01.jpg and Acanthostichus hispaniolicus SMNSDO5205-1 02.jpg https://commons.wikimedia.org/wiki/File:Acanthostichus_hispaniolicus_SMNSDO5205-1_02.jpg show the same ant specimen, so they should link to the same Wikidata item
Maintaining a large directory of small things may be quite a burden for the community. but I guess that if you donate the associated images at the same time, the benefit would be more obvious to the community, so they would more readily accept to do it :).
On Sat, Oct 25, 2014 at 2:39 PM, John Cummings < John.Cummings@wikimedia.org.uk> wrote:
I'm not sure if this quite fits here but it's related.
A few months ago I went to a meeting of natural history organisations in the UK, they were looking for a way of creating a centralised directory of specimens held in different institutions in the UK.
Wikidata seems like a possible place for this to happen, for each species there could be a place where specimens are held, however there would be very large differences between number of organisations holding specimens depending on the species and also differences in types of specimens e.g jaw bones or whole skeleton. I also wonder if this would include other organisations like zoos where they would be alive.
Any thoughts would be welcome
Thanks
John
On 24 October 2014 22:09, James Heald j.heald@ucl.ac.uk wrote:
Hi Daniel, thanks for getting back to me.
A couple of quick points, which I digest in more detail what you've written:
(1) I don't think that one can say a-priori that for all files based on a specific book, the same approach would be chosen.
If you look at either of the categories I cited, you can see we have files being contributed by multiple different uploaders, from multiple different sources:
https://commons.wikimedia.org/wiki/Category:Twenty-four_ Views_by_Henry_Salt_%281809%29
https://commons.wikimedia.org/wiki/Category:Pyne%27s_Royal_Residences
Some have uploaded a single file, some have uploaded multiple files. There's no reason to assume they would all adopt the same approach without strong guidance, and even then it would be questionable.
(2) It's really important to link together all the people that made a contribution, what that contribution is, when it was made, and what rights there are on it.
I don't think this can be done using qualifiers on a contributor property, because there may be more than one contributor involved.
(3) If we make it hard to move work-information easily, and as a unit, between file-data and item-data we're going to really make things difficult.
(4) It is essential to be able to order the hit-sets of searches, eg analogues of the current category view, and there are likely to be a number of different standard orderings that should be available.
If this requires coping with the fact that some of the information will be stored in file-data and some will be on Wikidata items referenced from file-data, that needs to be designed in right from the start as a basic requirement.
Cheers,
James.
On 24/10/2014 20:51, Daniel Kinzler wrote:
Am 24.10.2014 02:17, schrieb James Heald:
I think the issue I'm stuck on is: what property would the qualifier be attached to ?
...
The first choice might be attaching the information to a "Creator" property.
I would prefer "Contributor", but yea, something like that.
But for the underlying works of these engravings, there are typically
*two* creators, both of which are significant -- the artist, and the engraver.
You can have any number of Statements about a Property, and each of these Statement has it's own set of Qualifiers (and Source References). E.g.
Contributor: Henry Foo Point in time: 1872 Role: Engraver
Contributor: Melissa Bar Point in time: 1870 Role: Illustrator
So instead, we might consider an "Underlying work" property, analogous
to the "Work" class in the Multimedia API development, "a creation to which copyright, authorship, etc is attached", as per
https://docs.google.com/document/d/1tzwGtXRyK3o2ZEfc85RJ978znRdrf 9EkqdJ0zVjmQqs/edit#heading=h.akjw1xj0kfpf
But can we then capture the whole of the work class in such a property?
No. Using "Underlying work" (or, as I would prefer to call it "Derivative of"), the Work has to be modeled as an Entity in it's own right - either a Wikidata Item or a MediaInfo entity.
There seem to me a couple of issues:
(1) What should be the value of the property? There doesn't seem to be an obvious choice (eg if one were importing from a repository or catalogue). What would be the datatype, and what should we store for this field.
It would be a reference to another Entity. Only the ID would be stored.
(2) It seems to me that we would need to enable qualifiers on
qualifiers -- for example, if we represented the creator of an underlying engraving using a qualifier, we would then seem to need another qualifier to indicate whether the role was as artist, or as engraver.
See above: there is no need for this, since we can have any number of "top level" Creator/Contributor entries.
In some cases, the contributor's role may be implicit by using a more specific Property, like Painter, Director, etc.
Similarly, if there is sourcing, there are sources that might apply to
one (1st level) qualifier, but not another. But normally the WD sourcing model is for a whole statement, not part of it.
They would apply to one *Statement* but not the other:
Contributor: Henry Foo ... Reference: Title: Detailed Research On That Book DOI: ... Reference: Title: My Art WEbsite URL: ...
Contributor: Melissa Bar ... Reference: Title: Awesome Art Book Author: R.N. Dewy ISBN: ...
What we're would really be doing, if we did this in full, would be in
effect to store the contents of what might otherwise be an entire item in a property.
If we have that much relevant information, it might be worth creating a data item. Especially if we end up repeating that info for multiple files (e.g. engravings from the same book).
This can and should be decided on a case by case basis. Just like on Wikipedia, it makes sense to create a separate Article when a section of some more general article grows too big.
That has some attractiveness, if at a future time one wanted to promote
the 'underlying work' to have a Wikidata item in its own right -- the two structures would then match exactly.
But it would mean CommonsData having a slightly different data structure to Wikidata.
Slightly different isn't a problem, but the ability to "nest" entities and/or qualifiers is a fundamental structural incompatibility. That's not good.
...
If we're looking to support these searches and orderings, does it matter that a particular field may sometimes be on the file item, but sometimes on a Wikidata item ?
Searching (or rather: querying) across both datasets at once would be nice, but that'S pretty far off. First, we need decent query capabilities for the individual datasets.
I would imagine that for all files based on a specific book, the same approach would be chosen (e.g. a Wikidata Item for the Book, and MediaInfo for each file).
Note that Queries are different from Searches. Searches are ranked and potentially open-ended. Queries have a definite result set, and may be sorted. Queries will (in the future) be pre-defined and cached, and can be used on wiki pages via Lua, to create a list or table based on whatever logic you like. On that level, it would also be possible to combine information from two repositories (Wikidata and Commons), but at that point, we are talking about proper programming in Lua.
Would it matter that for one of the engravings we have two copies, so
the information that we would be wanting for search and selection and ordering would be stored on a Wikidata item; whereas for the rest, with only a single copy, it would be stored on a Commons item? )
It would be tricky to manage this nicely for the general case. For your specific book, you may write some specialized Lua code that deals with this.
However, I would not recommend to create a data item just because you have two files in a single case. If the relevant data is not too extensive, it's fine to duplicate it.
None of these questions are without solutions. But it does, I think,
require a decisive view to be reached, as to what we propose to do.
I think there are two main parts to your questions:
a) How to model contributions without modeling all the "base works" separately. I think multiple Contributor statements with separate lists of qualifiers and source references cover this.
b) How to best integrate the information that lies partially on Wikidata, and partially on Commons. This is indeed tricky, and perhaps there is no general, one-size-fits-all solution.
One thing that may help is the planned "high level media info API", which provides license/attribution/legal information about files in a unified form, drawing from structured data both on Commons and Wikidata.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
-- *John Cummings - **Wikimedia UK volunteer* tweet @mrjohnc
Wikimedia UK is a Charitable Company registered in England and Wales. Registered Company No. 6741827. Registered Charity No.1144513. Registered Office: 4th Floor, Development House, 56-64 Leonard Street, London EC2A 4LT. United Kingdom. Wikimedia UK is the UK chapter of a global Wikimedia movement. The Wikimedia projects are run by the Wikimedia Foundation (who operate Wikipedia, amongst other projects). Wikimedia UK is an independent non-profit charity with no legal control over Wikipedia nor responsibility for its contents.
Telephone (0044) 207 065 0990.
Visit http://www.wikimedia.org.uk/ and @wikimediauk
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l