Thanks for the pointers, James! I'll try to digest them.

Our thoughts on the issue of representing relationships between works are not fully formed yet, but the current idea is loosely that

* if the original work has a Wikidata item (according to whatever notability guidelines the community prefers), link to that

* otherwise if it is a Commons image, link to the local data item of that image

* otherwise representing the relationships in full detail is probably not that important, so it's fine to just add the authors of the originals as contributors to the CommonsData entry with some generic role such as "author of a source work", without trying to represent the accurate relationship between them.

So, if there is a chain of "derivative of" relationships between works which have Wikidata or CommonsData items, we can walk the chain upon extraction and collect the authors. Where the theoretical chain extends outside Wikidata+CommonsData, the actual (as stored in Wikibase) chain would have author information from the outlying nodes "squashed" into the edge nodes.

On Mon, Oct 6, 2014 at 11:08 AM, James Heald <j.heald@ucl.ac.uk> wrote:

Gergo,

Thanks for this -- and hoping you have a very productive set of sessions, to all of you in Berlin this week.

Yes, where one has a derivative work of another Commons work (a restoration, or a cropping, say), I can see it makes sense to point to the CommonsData entry for that other work.

But I guess you need to ask yourselves how much of a chain you're prepared to walk, if that file in turn points to data on an underlying physical work. Do you extract the "original creator" through the chain, or link directly? And what if there are multiple original creators?

I don't know whether it makes sense to have "original work" items on CommonsData rather than WikiData, more generally. (And here I'm talking about an "original work" in the sense of an original physical old photograph, or map sheet, or manuscript folio). As someone has pointed out, there are issues about having to deal with things in two places, and questions whether it would still be findable, if for example one were trying to search WikiData for all objects created by a particular creator.

I think this is something we simply have to defer to you, the technical designers of the system, for your considered view on what is the best way forward.

But I would commend some of the discussions at
https://www.wikidata.org/wiki/Wikidata_talk:WikiProject_Visual_arts
to you, not least for some examples file-cases that you might want to consider, for questions like:

* How to treat engravings from books?
* What "original works" should (or should not) get their own WikiData items?
* Could an edition item on Wikidata be enough to contain all the relevant information not held on CommonsData about an illustration?
* What if the same engraving appears in different books?

* If there are a number of pictures from a particular scan-set, should the scan-set have a Wikidata item? (Because there is information we may want to store about the scan-set, eg its source; and we may want to filter by it; and sort members of it according to a qualifier, numerical position in sequence)

Also I would very much commend to you the existing Wikidata schemas for artworks, for book editions, and for book works, as well as the work done by the old maps project:
https://www.wikidata.org/wiki/Wikidata:WikiProject_Visual_arts/Item_structure#Describing_individual_objects
https://www.wikidata.org/wiki/Wikidata:WikiProject_Books#Edition_item_properties
https://www.wikidata.org/wiki/Wikidata:WikiProject_Books#Work_item_properties
https://docs.google.com/spreadsheets/d/1Hn8VQ1rBgXj3avkUktjychEhluLQQJl5v6WRlI0LJho/edit#gid=0

which already go a long way towards creating a structure for storing information about many sorts of objects.

Finally, on a more general point, I would beg all of you in Berlin this week: don't despise wikitext.

It's easy to think that a shiny new system will displace everything. But there is lots of information, and tools, based on old-fashioned wikitext that it will need to integrate with for the foreseeable future. Wikitext is a straightforward API that a lot of content, and a lot of tools have been built on. So please do think how you can work with that, rather than simply deprecate it.

Vandal-fighting tools in particular are based on changes to Wikitext, so please do consider that it would be good to be able to represent changes in the WikiData or CommonsData in ways that tools based on existing wikitext file pages can pick up and if necessary revert.