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.cummi...@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.he...@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 > >
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
