I know the categories in Commons exist. I also know that you do not have to add categories when an image is uploaded. Many people do not consider the categories because they are just there and are not easy nor obvious without a long study. 

They are there and they evolve. When the "community" finds that they are no longer useful, there will be others who still want to work on it. They can, it is a harmless occupation. Why would we consider removing category structures as long as someone cares about them ??

On 18 August 2014 23:48, James Heald <j.heald@ucl.ac.uk> wrote:
Whilst that may be so, please nobody suggest dismantling any categories on Commons, unless and until Commons specifically asks for it.

As I learnt today, some on Commons are touchy enough just about the *idea* of Commons Wikibase, never mind anything being stored on it.


Probably I was being over-facetious with my selection of the words "Midsummer Morning" in my example.  (But then it wasn't me that assigned Q42).

The serious point is that I do believe there will be valuable-to-identify sets and subsets that may not be captured just by properties (unless the property is "belongs to this particular set")

So it wasn't just pictures taken from *any* cellphone *any* midsummer morning I was looking to identify, but pictures from one particular cellphone one particular midsummer morning, that happened to make a set.

Similarly I think it is possible to imagine other useful sets that wouldn't be necessarily be identified by a property that pointed to something with a particular Q-number; nor even a combination of such properties.

  -- James

On 18/08/2014 18:53, Magnus Manske wrote:
If I may chime in: Most, if not all, of the (overly specific) categories on
Commons can be expressed by statements. So, storing the data/time from EXIF
or otherwise would allow for a "midsummer morning" query. Adding EXIF
camera model to the file data item would allow to query for cellphones (it
would probably reference the cellphone model item on Wikidata, which in
turn is an instance of cell phone).

This can be done with live queries a la WDQ, or stored procedures a la
"complex queries" which are planned for Wikidata, as a click-on category
replacement, if such a thing is desired.


On Mon, Aug 18, 2014 at 3:22 PM, James Heald <j.heald@ucl.ac.uk> wrote:

Thanks Lydia!

Something that occurs to me is that one may well want to include Commons
categories in such a database, not just files, which presumably might be
stored on a page like

   Info:Category:Insert random Commons category intersection here

so that one could then ask whether a file belongs to such a category or
not, and the data would all be in the database.

Such categories (or sets) may well not be Wikidata notable, for example:

   Category:Pictures I took on my cellphone one midsummer morning

so we cannot assume they have Q-numbers.

But it would be nice if we could describe such properties using the
existing Wikidata syntax, ie via a property Pxyz = "belongs to set", and
then an item number for the set it belonged to.

Since the items wouldn't be on Wikidata, it would be useful if they had a
different namespace,  eg   C nnnnnn

Of course some of the categories would be on Wikidata,  so for such
categories one would want to create a tie between the item on Commons
Wikibase and the item on Wikidata,

    C nnnnn <--> Q mmmmm

Sorry if I'm being premature and getting ahead of things, but this is the
sort of thing I had in the back of my mind.

On the other hand I can quite see if, to start with, you want only to have
files as items on Commons WikiBase  (CWB ?).   But even then, it's quite
nice to have an Wikidata-style identifier syntax for talking about them,
eg  C nnnnn  again.

(I'm not particularly hung up about the "C" -- it could be anything. But
"F" for file is perhaps potentially too restrictive for future development).

Just typing out of the top of my head here,



Wikidata-l mailing list