https://bugzilla.wikimedia.org/show_bug.cgi?id=39150
--- Comment #3 from Daniel Kinzler <[email protected]> 2012-09-11 08:00:22 UTC --- I would thing that an empty item is empty. It contains nothing. No label, no description in any language, nothing. I don't think we should consider an item that has a label as empty. Programatically, this is defined by ItemContent::isEmpty() - but there's currently no way to query that in the database. Eventually, page_site should be usable for this, but currently, the number there is not very meaningful, and never null. I think for empty items it's currently between 2 and 14 or something (it counts bytes in the item's serialized form). Anyway. Re your first definition: does that mean it has a label or a description in only one language? Or in any number of languages? Note that there will be quite a few items that just have a label and a description, often only in one language. I would consider these "stubs", not "empty". They will often be created when filling in a property of the type "item reference", when the respective target item doesn't exist yet: if I want to provide the mayor of a city, but the mayor has no Wikidata item yet (and no Wikipedia page in any language), I'd just give a label and description, and the system would create a stub item. Re your second definition: there will be quite a few items with no Wikipedia links that cant have Wikiepdia links because there just isn't any Wikipedia page about them. Stubs like the above, but also books needed for citations, etc. They should not be considered empty. All that being said, I think it would be useful to have lists for all of these: empty items, "stub" items (label and/or description and/or aliases only), and "unconnected" items (items with no sitelinks). It's currently not trivial to get these lists from the database, and I imagine we might get even more involved definitions once we have full support for properties (and maybe things like categories). One solution would be to detect these "states" of the item whenever a new revision is saved, and store them to the page_props table. Yea, thinking about it, that's probably the way to go. ItemContent (or better, EntityContent) should get a getPageProps() method that would be used to push the appropriate page_props into the ParserOutput object returned by EntityContent::getParserOutput. That should cause these props to be saved in the DB, which makes it easy to construct the respective lists. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
