Commons talk:Wikidata for media info

Subpage vs. namespace

Wouldn't Info:Berlin.jpg make more sense than File:Berlin.jpg/info?

Not when you think about renaming or deleting files. The idea is that the meta info is really bound to "its" file. But technically, it does not make much difference, it could be done either way. -- Daniel Kinzler (WMDE) (talk) 13:32, 25 June 2013 (UTC)[reply]

But technically, File:Berlin.jpg/info is a File page in Mediawiki, i.e. there is the assumption that this refers to the actual binary media file "Berlin.jpg/info", not "Berlin.jpg". --G.Hagedorn (talk) 21:56, 25 June 2013 (UTC)[reply]

Separately, I find the /info confusing. The data on this page are (in a semantic web sense) about the media object, not about an information resource that is about the media object. I realise that compatibility problem may exist to use the File: namespace itself, but I would favor something as close as possible, like Fileobject:Berlin.jpg, something that stresses, like for item:, that we are talking about a semantic web world of things, not web pages. --G.Hagedorn (talk) 21:59, 25 June 2013 (UTC)[reply]

File:Berlin.jpg is not an actual binary file, it's a wiki page about that binary file (technically, the identifier for the binary file is Special:FilePath/Berlin.jpg). File:Berlin.jpg/info is also a page about the binary file, maintained as structured data. But the info suffix isn't set in stone, we could change it to meta or about or whatever. A "dependant" namespace would also be possible, but I think it would be both harder to implement and less clear for the users. BUt I may be wrong there. -- Daniel Kinzler (WMDE) (talk) 18:33, 26 June 2013 (UTC)[reply]

If the talk page for Berlin.jpg is at File_talk:Berlin.jpg then shouldn't the data be at File_data:Berlin.jpg? Even if it does mean the 'File:' page and the 'File_data:' page share a talk page.
Personally I can't see why you need an 'info' page when it just has the same information as the File: description page - lets just make description page into an info: page. Filceolaire (talk) 23:01, 16 August 2013 (UTC)[reply]

Missing properties

There should be a "depicts" property, linking to a wikidata item. There should be properties for "current location" (item: museum etc). External identifiers, e.g. from museums. Source of the file (e.g. donated by a museum, created during "Wikipedia loves monuments")

Those are suggested properties, not the final set, which will be created like in Wikidata.--Micru (talk) 13:16, 25 June 2013 (UTC)[reply]

External identifiers should probably be items on Wikidata -- Daniel Kinzler (WMDE) (talk) 13:31, 25 June 2013 (UTC)[reply]

I was thinking about string-type object serial numbers assigned by the museum etc. that holds it. --Magnus Manske (talk) 13:53, 25 June 2013 (UTC)[reply]

Sure, that will be useful too. Whether that should be on the file or rather on the item about the artwork probably has to be decided on a case by case basis. -- Daniel Kinzler (WMDE) (talk) 15:51, 25 June 2013 (UTC)[reply]

You might want to look here at the properties already created: d:Wikidata:Artworks_task_force/Properties. Jane023 (talk) 05:48, 26 June 2013 (UTC)[reply]

Thanks & question

Thanks a lot for this proposal. I have some questions:

would it be feasible to factorize media info for several files (which may call for media info unattached to a given media file)? For examples:
- our versions of The Starry Night do not share metadata ;
- Mona Lisa do share through Artwork:Mona Lisa.
- our 6 versions of Bélisaire demandant l'aumône do share through the rather daunting couple {{Category definition: Object}} / {{Object photo}}
Creator data: values would be Wikidata items, but plain text would be accepted too, is that correct ? What about links to Commons users, or Flickr users? Should we create items for those? Must items exist on Wikidata, or could we have items stored here (assuming they are not in scope of Wikidata)?

Thanks, Jean-Fred (talk) 13:11, 25 June 2013 (UTC)[reply]

As to sharing meta data between representations of the same painting, etc: I think this is mostly useful in cases where the file is a reproduction or depiction of some famous piece of art. In that case, that piece of art can and should have a wikidata item, which would contain the shared metadata. Using data from that wikidata item directly on the image description page, along with file-sepecific meta data, is technically somehwat tricky, but should probably be made possible.
Good question about the data type of the "creator" property. I can see use cases for using Wikidata items here, but also for using local users or full URIs. Currently, this would require separate properties (creator/creatur-user/creator-uri), but perhaps we can come up with a better solution in time. -- Daniel Kinzler (WMDE) (talk) 13:39, 25 June 2013 (UTC)[reply]
- Or, we could proliferate the properties, "Wikimedia user", "Flickr user", and just store the user handles in a non-translated string. The property could then be used to construct URIs on the fly. --Magnus Manske (talk) 14:12, 25 June 2013 (UTC)[reply]

Creation of Wikidata items from Commons

Will it be possible to have an interface to create Wikidata items from Commons? It might be quite annoying to have to come to Wikidata to add missing creators, works, etc.--Micru (talk) 13:18, 25 June 2013 (UTC)[reply]

I imagine someone will make a gadget for that. -- Daniel Kinzler (WMDE) (talk) 13:40, 25 June 2013 (UTC)[reply]

Replacing the file description page?

So if it can have any fields we as a community choose, then it would basically be a structured version of the current file description pages? Would the idea be to remove the information from the latter (sounds hard on commons editors, especially newcomers), or maintain both simultaneously with equivalent data (sounds dangerous given that they would soon get out of synch)? --99of9 (talk) 14:04, 25 June 2013 (UTC)[reply]

I would strongly recommend migrating the data from the description pages to wikidata. Such a thing would, of course, need to come with some kind of sane editing interface on Commons for the data, I imagine... --brion (talk) 15:06, 25 June 2013 (UTC)[reply]

Thanks for the reply. Do you consider everything that is currently on the file description pages to be "data"? What about awards / quality assessment templates / special messages from the author / original upload logs / maintenance templates / categories...? Do they get left behind as the only thing a user sees when they click "edit"? That could be confusing since the usual thing they will want to edit is the file description. So I agree we'd also need to be given a fantastic editing interface. My next question is, since you propose we basically replace at least the current info templates etc, how would the data be migrated and what would editing look like during the half-migrated stage? --99of9 (talk) 15:20, 25 June 2013 (UTC)[reply]

@brion: the idea is to store the meta data as structured data using Wikibase on Commons, not on wikidata.org.

@99of9: I think most of what is commonly on image dscription pages can and should be migrated to the meta data page (that is, into the media-info entity). Anything that really needs wikitext syntax would stay on the description page. Categories will probably also not be handled via the meta page (though properties like "topic" or "depicts" could work similarly to categories, with the advantage of being cross-lingual). -- Daniel Kinzler (WMDE) (talk) 15:55, 25 June 2013 (UTC)[reply]

So the description parameter would be limited to plaintext? Is this a unbreakable limitation? It is quite common for example for the description field to contain italic species names and links to multiple wiki articles. Would that still be possible if the description field was migrated? --99of9 (talk) 22:17, 25 June 2013 (UTC)[reply]

I would really like to avoid wikitext in data items. It misleads people into using wikitext for cross references when it would be much better to use separate properties. The context for parsing is unclear, handling of languagelinks, categories, etc is unclear. Also, wikitext depends on a lot of parameters and is hard to render correctly outseide the original project.

It's not totally impossible to support this, but I don't think we will unless there is an absolutely compelling reason. -- Daniel Kinzler (WMDE) (talk) 14:47, 28 June 2013 (UTC)[reply]

Using wikidata.org

What is the reason behind creating a extra database instead of using simply wikidata.org? --FischX (talk) 22:49, 25 June 2013 (UTC)[reply]

The idea is that the meta data should be stored and maintained where the actual files are stored an maintaned. For one thing, this makes it much easier to integrate with the upload process and keep the data in sync when files get renamed or deleted. There will however be a tight integration with wikidata; in particular, it will be possible to reference data entities from one project to the other. -- Daniel Kinzler (WMDE) (talk) 14:43, 28 June 2013 (UTC)[reply]

Licenses

We could use the qualifiers to add individual notes to licenses; some licenses allow that the author specifies a specific way to be cited. A "cite as" qualifier property would solve that neatly, with fallback to the default citation in the absence of the qualifier. --Magnus Manske (talk) 14:15, 25 June 2013 (UTC)[reply]

Video data layer

Mediawiki at Wikimedia Commons still doesnt show data from Teora data layer, would you be able to retrieve such data?--Juandev (talk) 15:02, 25 June 2013 (UTC)[reply]

Retrieving/extracting data is beyond the scope of this proposal. It's technically possible to extract the data, and such data can be stored on the meta data page. When and how this is done is a different question. I assume that the arguments would be the same as for EXIF data from images -- Daniel Kinzler (WMDE) (talk) 15:57, 25 June 2013 (UTC)[reply]

More properties for complex description

Would it be possible to store at Wikidata more parts of description. I mean if we get files from GLAM, they usually have more information about such files.--Juandev (talk) 15:02, 25 June 2013 (UTC)[reply]

As far as I'm aware, we already try to preserve all metadata that the GLAM provides, even if it is not visible output of the template on the file page, the data should usually be in there. --99of9 (talk) 15:22, 25 June 2013 (UTC)[reply]

As part of the import process I suppose you would map the GLAM data fields to equivalent Commons data properties, creating new properties if needed. Alll the info would be stored on the info page. Filceolaire (talk) 23:21, 16 August 2013 (UTC)[reply]

Another level of complexity

Wikidata will add another layer of complexity to Commons, a project that is already difficult to edit and maintain.

Wikimedia Commons hosts far too many files which …

… have no description or are insufficiently described (“can’t be found”)
… are not or insufficiently categorized (“can’t be found”)
… are not properly licensed
… are not free content

We struggle for years with issues like that, but there has been no significant improvement (wait, we have bots that place an “own work” statement in files that are obviously not own work, drawn from a license template which is explicitly no replacement for such a statement …).

“The properties that can be used to make statements about media files will be created and maintained by the community, just like this is now the case on Wikidata.” No, this is not how Wikidata works: Wikidata mainly uses bots to create and change entries. And if not: How should a community that hasn’t the ressources to make Commons a well-sorted, well-described and clean media repository help on Wikidata?

Just some hours ago, I corrected a wrong place of death on de.wikipedia.org. Although all other Wikipedia projects showed the correct place, a bot had already transferred ("source: German Wikipedia") the wrong information to Wikidata. Given the fact that only a minority of active Wikipedia users participates in Wikidata, most local corrections won't find their way to Wikidata and information on Wikidata might be wrong because a lot of entries have never seen a human contributor who checked unsourced information provided by some template in some project. As an average user I see no fundamental ambitions to address such issues.

Why should this be different to Wikidata for media info? The main difference I see: Commons provides much more false/fake/insufficient information to bots than the average Wikipedia project. --Polarlys (talk) 15:47, 25 June 2013 (UTC)[reply]

Honestly, I see less complexity. Eventually, this will hopefully allow peopel to maintain commons without knowing english, having to mess with templates, or having to deal with the category structure. To reply to some of your statements directly:

"properties ... will be created and maintained by the community" refers to the properties themselves, not the statements that use these properties. Properties on wikidata are not created by bots.

Insufficient descriptions and bad categorization will hopefully be improved by the ability to more easily provide descriptions in multiple languages and, more importantly, by using wikidata items to indicate content and topic. These would act as cross-lingual "tags", that I hope would make search and navigatioon on commons a lot easier (though it will take some time until the appropriate tools and interfaces have been developed).

The ability to retrieve meta-information like licenses in a structured form from a machine readable interface will, hopefully, make it easier for bots to find and fix problems.

I do not see how maintaining meta data in a structured way would cause any additional problem; it should make the maintenance of meta data simpler (who likes to edit info templates?) and should not add extra work (except for an initial bot run to move things from info templates to the meta page). It would also make it a LOT easier to write tools to help with maintenance, not to mention re-use.

-- Daniel Kinzler (WMDE) (talk) 16:07, 25 June 2013 (UTC)[reply]

Thank you for your reply and my mistake regarding properties. I regularly mix up terms regarding Wikidata. --Polarlys (talk) 18:59, 25 June 2013 (UTC)[reply]

Authorship

How to identify authors ? In case no own Wiki*ans, it would be nice that the author property would be linked to more than a textual signature, like to the account of the author in Wikidata. Is something like that planned ? Now that accounts on the different project are linked, a user datatype would be nice as well. TomT0m (talk) 16:46, 25 June 2013 (UTC)[reply]

Editing

If I understand correctly, the idea is to have an "info" page that will not be shown in raw format by default, but formatted in the file description. The big plus side is that it will not break templates and other fancy wikitext, but I am slightly worried about the editing experience, as it will split the file description into two pages. --Zolo (talk) 17:13, 25 June 2013 (UTC)[reply]

That is also one of my concerns. My other concern is that the concept of having a sort-of-wikidata which links to wikidata might be difficult to grasp by new users. --Micru (talk) 17:51, 25 June 2013 (UTC)[reply]

Metadata

Commons file description usually have uneditable metadata at the bottom of the page. They are not very visible, and sometimes, users feel compelled to repeat it in the Wikitext. Also the "date" section of {{Information}} is often just a copy of the date in the metadata. This is highly redundant and not very transparent (if the data shown is just a copy of the metadata, it should be indicated more clearly. Is there a plan to better integrate undeditable metadata with other info ? --Zolo (talk) 17:13, 25 June 2013 (UTC)[reply]

Sounds promising

A few thoughts and questions:

The license should be only editable by the uploader (and possibly by bots or admins) … would this be possible?
Can someone give an example how a media-info item would look like for a musical work ( text by person a) music by b) performance by c) recording by d) )? I never worked with WikiData and can't imagine how to associate which license tag with which creator and date.
The community will have to care for the migration of all the description data to the media-info entity, correct?
(How) will this be integrated in upload tools? Currently some guys want to add JSON data to our templates.
- Will we be able to block upload from tools that are not updated to the new system?
Can you give an estimated time spawn for the development-duration?
Will using WikiData enable searching and filtering by license (immediately/future)?
-- Rillke^(q?) 17:15, 25 June 2013 (UTC)[reply]

- Just a comment that I frequently edit other uploaders' licenses (generally, when they have indicated PD-Art without the US PD-old-100 or similar) - PKM (talk) 23:52, 25 June 2013 (UTC)[reply]
  - This is legitimate but licenses of works identified as "own work" should not be editable by everyone. The responsibility to choose the correct license is the uploader's and this step will prevent edit warring (e.g. in case of copyfraud); instead the user could be simply blocked if it is found that this is an issue and this step would also help to prevent license-vandalism. The impacts license-vandalism are simply too serve given the fact that we do not manage to patrol all anon edits. -- Rillke^(q?) 07:37, 26 June 2013 (UTC)[reply]

(I took the liberty to change your post to a numbered list, to make it easier to reply to each point).

ad 1: theoretically yes, but I'd generally prefer such a restriction to be enforced by the community, as a convention.

ad 2: In the wikidata data model, you can have multiple statements for each property, and each statement has a "main" value plus "qualifiers" and sources. In the case of a mulsical work, I would weither use multiple properties ("composer", "performer", etc), or a single property with multiple values and qualifiers, such as "copyright-holder (role: performer)", "copyright-holder (role: composer)", etc. On Wikidata, we do simmilar things with actors starring in specific roles in files.

ad 3: yes. Just like the migration of language links and infobox data into wikidata, I expect this to be done by a handful of bots.

ad 4: there are no concrete plans yet, but I'd expect the uplkoad form will put information directly on the /info page instead of generating an {{information}} template. Blocking "old" upload tools is probably not a good idea, but that's up to the community.

ad 5: i can only give a rough guess at the timeline, since the feature set is not clear yet, it's unknown what other projects we'll have to tackle in the mean time (Wiktionary?), and what menpower we'll have (funding). My rough guess is "some time next year".

ad 6: eventually, yes, but not right away.

-- Daniel Kinzler (WMDE) (talk) 09:20, 26 June 2013 (UTC)[reply]

Excellent Idea and Strong support

nothing more to say --Renepick (talk) 17:53, 25 June 2013 (UTC)[reply]

yay, thanks :) -- 93.220.93.234 18:25, 26 June 2013 (UTC)[reply]

Agree Ainali (talk) 08:23, 29 June 2013 (UTC)[reply]

How will Institutes, creators, categories fit in ?

Many media objects have common objects: institutes, categories, creators? How will they fit in ?

Will Wikidata be part of the items searched in the search database. Search has substantially improved and Commons is becoming some sort of translation engine.

Will the interlanguage links become part of wikidata and will they be searchable ? --Foroa (talk) 18:04, 25 June 2013 (UTC)[reply]

For artworks, Institutions and Creators have VIAF entries and should already exist in Wikidata - there should be a way to link this info without making duplicate records that would get out of sync between Wikidata and Commons. It would be nice to have a searchable interface that would create the link for the user, so they could enter "Van Gogh" and find the matching record(s) to choose from. - PKM (talk) 23:56, 25 June 2013 (UTC)[reply]

Institutes, categories (topics), and licenses would be identified by "items" on wikidata.org. Creators would be in some cases (artists) - in other cases (own work) the creator would refer to a local user (for technical reasons, this would require us to have two creator properties: "creator" and "creator user" or some such).
Yes, the meta data should be searchable, using information in all languages, partially taken from wikidata.org. This will probably not happen right away, but I very much hope that we will get that integration rather sooner than later.
Interlanguage links could be managed via wikidata.org, but that's entirely separate from this meta data proposal. Note: using wikidata for language links and infoboxes is "client" functionality, like Wikipedia uses it too. Maintaining meta data is "repo" functionality. These are largely unrelated in terms of feature sets and deployment (meaning, we can deploy one with the other, they are separate extensions).
-- Daniel Kinzler (WMDE) (talk) 09:28, 26 June 2013 (UTC)[reply]

Why not use the description page?

Why not add these metadata to the description pages that would store the metadata + the wikitext in an hybrid storage ie in a JSON tree with a node "wikitext" that would have for value the description page as before? This solution would keep the two elements, metadata and wikitext content in the same page for an easy manipulation and avoid the need to navigate between the two pages (the description page and the /info page). That would also allow, if the community wants, an easy migration in an undetermined future from this hybrid content storage to a storage based only on Wikibase statements when a wikitext based storage will be no longer needed (the categories replaced by good Wikibase queries...). This migration would be done by only removing the "wikitext" field of the tree. The revisions before the introduction of this feature would be seen as a tree with only the "wikitext" node and without statements. Tpt (talk) 18:36, 25 June 2013 (UTC)[reply]

Because that would make the migration much more painful and brittle. Much better to add to a running system than to try and replace it in mid-air. -- Daniel Kinzler (WMDE) (talk) 09:29, 26 June 2013 (UTC)[reply]

Alt text

I think it would be helpful to provide a way to store an alternative description of an image that can be used by the visually impaired. Currently we expect each article use to provide ALT text in the image link, along with the caption. This rarely happens. Allowing for a default ALT text stored with the image that would be overridden by an article specific ALT could do no harm and might increase usage of the ALT feature. Of course multiple languages would be allowed, and having the ALT text in a centralized location would permit one language's description to be translated or adapted for another language.--agr (talk) 18:06, 4 July 2013 (UTC)[reply]

I agree. Each file should have a multilingual 'Label', like wikidata items have, that can be used as a Caption and as ALT text. Filceolaire (talk) 23:43, 16 August 2013 (UTC)[reply]

Shared properties namespace

Would it be technically feasible to auto-import all property definitions (Pnnn) from wikidata, and make them non-editable on commons ? This way, talking about "property P603" remains unambiguous across all of WikiMedia. When a new property is discussed and approved on commons, it could then be added to wikidata.

This might also make sense for categories, though I'm not sure where wikidata stands wrt this.

Also, if the data items would be automatically numbered, could you please use a different identifier than Q, e.g. "Fxyz" (for file # xyz) ?

--Pixelpapst (talk) 11:14, 7 July 2013 (UTC)[reply]

I like the idea of using properties defined on wikidata, but that means quite a bit of additional development work. How important do you think is this?

As to the IDs: media info pages would not be numbered, they would have IDs like File:Berlin.jpg/info. We may need some numbering internally, but it wouldn't matter to the user (like mediawiki page IDs). -- Daniel Kinzler (WMDE) (talk) 20:57, 15 July 2013 (UTC)[reply]

Lets do Phase 1 first

This Proposal seems to be for Phase 3 or 4. I think we need to start with simple "Phase 1" and "Phase 2" supporting interwiki links between wikipedias and Commons Categories and Galeries and properties. I do a lot of maintenance of Creator and Institution templates, and I do not think they have to be directly connected to wikidata since they all store name of Home category. So as long as syntax like {{#property:date of birth|of=Albert Einstein}} works (where Albert Einstein is a category name), we should be fine. --Jarekt (talk) 04:28, 10 August 2013 (UTC)[reply]

Actually, at the moment, wikidata data can only be retrieved on a page that is directly linked to the Wikidata item, so that the birth date of Albert Einstein could be displayed on the page dedicated to him, but not transcluded on other pages (bugzilla:47930). Beside that, I am wondering if we would really need phase 1 on Commons. Ideally, I think we should get rid of the creator and institution templates, and perhaps even of categories. --Zolo (talk) 11:10, 10 August 2013 (UTC)[reply]

I agree with Zolo. Since it seems the function of categories can be better achieved by Wikidata properties and queries, in my opinion we should be thinking about how we can replace the current categorization system on client wikis. Emw (talk) 14:05, 10 August 2013 (UTC)[reply]

For me "Phase 1" means interwikis and "Phase 2" properties. I am fine with eventually getting rid of creator and institution namespaces. I am also all for using alternative approches to categorization using wikidata properties, but I do not think we will be getting rid of categories anytime soon, on commons or wikipedias . In the mean time we need "Phase 1" and "Phase 2" (wikidata powered interwikis and properties). --Jarekt (talk) 16:38, 10 August 2013 (UTC)[reply]

Phase 2 may indeed be useful, but mostly if bugzilla:47930 is solved, imo.

Phase 1 seems a bit tricky. I would think that the more useful thing would links between Wikipedia articles and Commons categories. But cross-namespace linking but not everyone likes cross-namespace links. Links between Wikipedia articles and Commons galleries is another solution.would probably be cleaner and clearer, and Wikidata will not make galleries obsolete. But I do not find Commons galleries tremendously useful. I think the best solution would be to be able to add one link per project per namespace on Wikidata, but that does not seem to be on the agenda. --Zolo (talk) 17:53, 10 August 2013 (UTC)[reply]

I am not proposing anything new. Currently we mostly have interwiki links between commons categories and wikipedia articles and commoncat templates linking wikipedia articles with commons categories. There are some gallery <-> article links but in most cases galleries are really out of date an only useful as a way to find a category (there are exceptions). It would be nice if interwiki links could be maintained through wikidata as they are for all the wikipedias. I think a single link from wikidata to commons category would be sufficient, but an option of an additional link to gallery would be better. I do not see a need for links to creator or institution templates, once bugzilla:47930 is solved. --Jarekt (talk) 21:10, 10 August 2013 (UTC)[reply]

We will still need to decide on whether we want to give priority to categories or to galleries. Generally we let users decide on the link, and it seems that tastes vary across Commoners (I once tried to delete completely outdated machine-created galleries with two images but got reverted...) I suspect that link from Wikipedias to Commons are not very consistent either, with some languages linking to categories and other to galleries. --Zolo (talk) 15:17, 16 August 2013 (UTC)[reply]

Rolling out language-link support so commons categories and galleries can automatically be linked to the respective wikipedia pages is already on the road map. I'm not sure about the exact date since Wikimania mixed up the regular deployment schedule, but if I recall correctly, it should be live by the end of August. -- Duesentrieb ⇌ 09:36, 13 August 2013 (UTC)[reply]

Great news. Thanks. --Jarekt (talk) 11:44, 13 August 2013 (UTC)[reply]

Image annotation

Not sure this has been suggested elsewhere before, but it would be interesting if images could be annotated with a direct link to the correspondent Wikidata entry. ~★ pikolas ^{[[mia diskuto]]} 02:56, 4 September 2013 (UTC)[reply]

Annotations can have any wikitext including images, tables and links. That include links to wikidata. --Jarekt (talk) 03:11, 4 September 2013 (UTC)[reply]

I wonder if it would be machine-readable, though. ~★ pikolas ^{[[mia diskuto]]} 23:24, 21 January 2014 (UTC)[reply]

Another comment

This is definitely a powerful proposal; I thought of something similar, before even chancing upon this.

Most categories will become obsolete: a simple query could select images by file extension, size in bytes, pixels, author, colors, subject, date of creation, assessment status, etc.

...such as:

--Ricordi samoa 13:43, 8 September 2013 (UTC)[reply]

BTW, we have 107,705,026 files to convert... it would be wise to develop a shared bot software for simple conversions, and a semi-automated one for experienced users. --Ricordi samoa 13:48, 8 September 2013 (UTC)[reply]

Sounds good. -- Rillke^(q?) 14:00, 8 September 2013 (UTC)[reply]

Be clearer

We can't manage parallel systems: this means that if you migrate data in Wikidata you can't do any data change about these data in Commons anymore. So each time someone wants to change some data of a file in Comons he will have to go to wikidata. So the Commons community will becomes the Wikidata community. Are you aware of that ? Splitting file data from the file itself is not a good idea Snipre (talk) 04:15, 10 September 2013 (UTC)[reply]

The proposal is about storing the data here and not on Wikidata. Did you see this? --Lydia Pintscher (WMDE) (talk) 18:10, 10 September 2013 (UTC)[reply]

@Lydia Pintscher (WMDE): maybe "Commons:Wikibase for media info" would be clearer? :-/ --Ricordi samoa 20:49, 17 January 2014 (UTC)[reply]

or just ComonsData. Filceolaire (talk) 09:45, 26 May 2014 (UTC)[reply]

conversion

i'm fairly neutral about this cproposal; i care about the end result in terms of data organization, usefulness, & useability, rather than whether we use categories, hashtags, wd "properties", etc.

BUT

if we do change from the system we are currently using, then we need to make sure that ALL the existing "properties" for EACH FILE are translated into the new data-structure.

right now, CATEGORIES ARE IMPORTANT; the data represented by a file's inclusion in a given category are a significant part of that file's "properties" (in wd terms). so, if we are going to do a mass-conversion, it's important that all of that information is NOT LOST. we've all done A HELL OF A LOT of work sorting media files into cats; & however we move ahead, there is NO NEED to REdo all of it.

so, i'd like to know what exactly is being proposed, instead of the rather wordy, rather abstract description in the draft text.

how this miraculous "conversion" is going to work?

AND i'd like to hear exactly how the conversion process will preserve the data "attributes" already attached to the files, especially those represented by categorization.

for that matter, in re-reading the draft, i find that there is in fact VERY LITTLE about the practical aspects of implementing this. how about some examples, test pages, demos, timelines, project pages, lists of: needed tools, tasks, etc., etc.Lx 121 (talk) 03:54, 22 October 2013 (UTC)[reply]

i'd also like to note that this discussion needs to be brought to the attention of the whole wmc community, BEFORE any decision is made about adopting it. because, right now, there only seems to be a relatively small number of people (with a particular interest in the subject) involved in the discussion (given the overall size of the common's community). a decision like this is too important, & too far-reaching, to be made that way. any "adoption" decision will not be legit, without a REAL community-wide consensus.

Lx 121 (talk) 03:49, 22 October 2013 (UTC)[reply]

If I read this proposal correctly, it is about using a separate page for metadata and transcluding them in the description page. So, by default, nothing would be removed from the file description. Removing categories would require someone (or a bot) deleting it and this will certainly be a long and tricky process. I suppose it will be more like: "Ok, the content of this category has been copied to the file info page and that works fine, now we can delete the category", than "now that that metadata seem to work fine, we can delete all categories". --Zolo (talk) 06:56, 22 October 2013 (UTC)[reply]

Or it can be read as "the metadata seems to work fine, we can improve our categories, by fixing/expading the existing ones". Sannita - not just another it.wiki sysop 13:54, 4 January 2014 (UTC)[reply]

Yes. The idea is that we'll be doing this large the way we've been doing it for Wikipedia. Provide better options and let the old things fiddle out over time. Templates on the image pages and categories will continue to work according to the current plan. But of course the idea is that we'll build more powerful tools which people will migrate to over time. --Lydia Pintscher (WMDE) (talk) 10:55, 26 May 2014 (UTC)[reply]

Idea

I have thought of a quite different architecture: the planned Wikibase-like extension should support keeping two separate content-models for file description pages: wikicode and json.

When this extension will be ready to use, it will be installed on Wikimedia Commons.
At first, we should give users the ability to upload new files with structured media info directly attached to the their description page, without a single line of wikicode.
Then, the extension should forbid users to edit old wikicoded file description pages.
Only a selected group of bots (for simpler cases) and humans (for harder ones) will be allowed to 'convert' wikicode into structured information, via (semi)automated tools.
The content-model will be changed irreversibly, but for single files, so every user will be allowed to edit information in the new JSON format (via a Wikidata-like GUI), once the 'conversion' is performed.
The original wikicode's history will be kept, alongside with the new history. Of course, the conversion will be recorded (in page history and/or logs).
Our community will have some time to develop new policies and adapt older ones to the JSON structured information.
Finally, when the transition is fully completed for all files, editing unstructured information in the File namespace will be impossible (see wikibase-no-direct-editing), and the current categorization system will be shut down permanently.

@Daniel Kinzler (WMDE) and Lydia Pintscher (WMDE): how about my proposal? --Ricordi samoa 17:33, 1 January 2014 (UTC)[reply]

I have no intention of forbidding editing image pages at this point. If the community at some point decides that is the way to go we can see. --Lydia Pintscher (WMDE) (talk) 10:56, 26 May 2014 (UTC)[reply]

I like the idea of the page content model changing from wikitext to media-info, however it needs to be revert-able, and the bots doing the conversion need to very well written and be much better controlled than they are on wikidata otherwise there will be a revolt. The conversion needs to be perfect, or the file skipped until the bot or wikitext are improved so that they understand each other. Ideally the conversion is actually done by a periodic run of a mediawiki maintenance script rather than bots. Also for this to work, I fear categories need to be supported for files using the media-info content model, otherwise the transition period will be difficult for everyone. The idea of a structured data only uploader is also great. John Vandenberg ^(chat) 11:26, 26 May 2014 (UTC)[reply]

A document for discussing properties and use cases

Can we start a document or a space or a task force to start discussing the metadata properties for the multimedia files? There are task forces for books and cultural heritage in Wikidata, but it would be good to discuss all the properties on a detailed level. I am interested in creating proper properties for historical maps. For the current environment we are preparing a Template:Map. In it there are properties that are shared with other current templates, such as Template:Artwork and Template:Book. In addition, we will need properties for expressing the geolocation of the map images and some additional options related to cartography. This data might be split between The Commons-wikibase and Wikidata. But we would only find out the optimal solution through bringing all relevant examples into discussion.

I would also love to see interface proposals there.

It goes without saying that I am pro this proposal in general. .Susannaanas (talk) 10:20, 26 May 2014 (UTC)[reply]

This is too early at this point imho. Also the current plan is to not have local properties but re-use what we already have on Wikidata. But we'll have to see as we make progress. --Lydia Pintscher (WMDE) (talk) 10:57, 26 May 2014 (UTC)[reply]

user:Lydia Pintscher (WMDE), It would be worthwhile writing up a new version of this page updating it with design decisions that have been made, and archive the current talk page. That will refresh the discussion around the current strategy. John Vandenberg ^(chat) 11:29, 26 May 2014 (UTC)[reply]

MIME type

Would it make sense to have MIME type as a property or are there better ways to enable queries based on that? --Ainali (talk) 20:50, 26 May 2014 (UTC)[reply]