Wikidata:Property proposal/description

From Wikidata
Jump to navigation Jump to search


Description[edit]

Originally proposed at Wikidata:Property proposal/Generic

   Not done
Description(aliases: Definition, Abstract, Summary, Curatorial comment, Biographic note): a well-edited short description of the item, with mandatory reference. Keep it short (a couple of paragraphs): Wikidata is not a full-text repository, and respect others' copyright.
Representsdefinition (Q101072), description (Q1200750), abstract (Q333291), summary (Q776754)
Data typeMonolingual text
Domainany entity
Allowed valuesReuse some great regexps from title (P1476) that warn on Latex chars, HTML tags, etc
Example 1rocking chair (Q14963)
  • "A chair that is mounted on two curved strips of wood (called rockers or bends) which connect the front and back legs, allowing it to be rocked backward and forward. It usually has a high, straight, or slightly curved back and often open arms.\nUsed for comfortable sitting or relaxing while rocking."
    language: English,
    reference: Nomenclature for Museum Cataloging (P7749) 1128
  • "Siège généralement à dossier haut et parfois incliné, avec ou sans accotoirs, dont les pieds sont munis d'arceaux qui permettent de le faire osciller de l'avant vers l'arrière par un simple mouvement du corps.\nPermet à une personne de s'asseoir et de se balancer."
    language: French,
    reference: Nomenclature for Museum Cataloging (P7749) 1128
Example 2The Virgin Cataphyge (Refuge) and St. John the Evangelist (Q84545297)
  • "Иконата е двустранна (лицева страна, от обратната страна е изобрзено иконата "Видението на пророците Иезекиил и Авакум"). Подарена е около 1395 г. от императрица Елена Палеолог, дъщеря на ктитора на манастира деспот Деян и внучка на цар Иван Александър, на Погановския манастир. Класическа красота, пропорционалност, аристократичност на колорита в духа на средновековната естетика."
    language Bulgarian,
    reference reference URL (P854) http://bidl.cc.bas.bg/viewobject.php?id=1&lang=bg
  • "A two-sided icon (the right side, on the back side is painted "The vision of the prophets Ezekiel and Habakkuk"). Donated about 1395 to the Poganovo monastery by Empress Elena Paleologus, daughter of the monastery's sposor Despot Deyan and granddaughter of Tsar Ivan Alexander. Classical beauty, proportionality, aristocratic colouring in the spirit of mediaeval aesthetics."
    language English,
    reference reference URL (P854) http://bidl.cc.bas.bg/viewobject.php?id=1&lang=en
  • Example 3Mother of God Pantonhara (Q84296272)
  • The Mother of God on this icon is depicted as an empress with infant Christ sitting on her leftarm. Both the Virgin and Christ are shown in imperial regalia. She is dressed in a purple-pink maphorion decorated with engraved, golden and green floral ornaments. Her chiton is green, ornamented similarly as the maphorion and decorated with two golden, crossed stripes with floral decoration. She has a golden crown on her head, a scepter in her right hand, while in theleft one she holds a huge stalk of wheat. Christ is dressed as the Grand Archpriest in a golden-orange vestment decorated with floral ornaments and golden stripes. In the right hand he holds a green sphere with cross, scepter in the left one and also a golden crown on the head. From left to the right there are shown: St. George, St. Demetrios, St. John the Baptist, St. Clement of Ohrid, St. Nicholas, St. Athanasios and St. George the New Martyr of Ioannina."
    language: English,
    reference described by source (P1343) The icon of the Mother of God Pantonhara in the Icon Gallery (Q84291564); Academia.edu publication ID (P7896) 9843052
  • Source
  • external equivalent property: dc:description, dct:description, skos:definition, skos:description, schema:description;
  • external subproperty: dct:abstract, schema:abstract (schema:text), bio:olb
  • See alsotitle (P1476), name (P2561), official name (P1448), native label (P1705), subtitle (P1680), media legend (P2096), currency symbol description (P489)

    Motivation[edit]

    Unlike WD props, the labels and descriptions on top don't have provenance. Furthermore, descriptions are intended to be short and used only for disambiguation, and don't have any quality control. To compensate, we have title (P1476), name (P2561) (and a whole slew of sub-props or variants like official name (P1448), native label (P1705), subtitle (P1680), media legend (P2096), currency symbol description (P489)) for labels. But there is no similar prop for Descriptions.

    • I propose one prop for several different things for now (Definition, Abstract, Biographic note) and we can specialize such props later: what do you think?
    • In many cases it's important to respect newlines, how could that be supported?
    • Maybe we could even use this for Song lyrics or Poem text? But I think that's going too far and we should have a separate prop for this. Should I propose one? (Moebeus expressed copyright concerns, so I'm dropping this idea, even though there are MANY lyrics sites)

    Vladimir Alexiev (talk) 09:36, 7 February 2020 (UTC)[reply]

    Discussion[edit]

     Support Makes sense to me. WD description fields are currently being used in many ways that are not compatible with "front-facing" display on Wikipedia etc. A dedicated property would help with that, querying would be easier, constraints could be written, etc. Moebeus (talk) 10:04, 7 February 2020 (UTC)[reply]

    •  Support --Crowjane7 (talk) 15:55, 7 February 2020 (UTC)[reply]
    •  Support --Brimwats (talk) 08:33, 8 February 2020 (UTC) -- as libraries, archives, galleries, and museums draw upon and use Wikibase more (such as Project Passage) the description text becomes even more important and essential for use.[reply]
    •  Support --illipmich (talk) 17:18, 7 February 2020 (UTC)[reply]
    •  Oppose primarily for the overt generality of this property. At least with something like scope and content (P7535) there are some constraints on its use and how it is structured, where here no such limitations on this proposed property's use exist. With respect to the front-facing aspect, Wikidata descriptions should in fact be usable as something that can be exposed to an end-user; the stuff useful only to a Wikidata editor should be placed in a separate Wikidata property (à la Wikidata usage instructions (P2559)) but the proper display of this property within the interface is presently blocked for technical reasons. Mahir256 (talk) 18:23, 7 February 2020 (UTC)[reply]
    •  Oppose I don't believe unstructured text belongs in Wikidata. We have had this conversation before and I can't remember precisely in what context - might have been "credit line". The sample text reads very much like the text type & length that used to be acceptable as a Wikipedia stub. That Wikipedia now has minimal length requirements is not a reason to put stubby text snippets in Wikidata. Also, such text descriptions of objects are generally copyrighted, if they are not from some 100-year-old catalog. Jane023 (talk) 19:22, 7 February 2020 (UTC)[reply]
    •  Oppose: unrelated with structured data. Nomen ad hoc (talk) 21:14, 7 February 2020 (UTC).[reply]
    •  Oppose inherently unstructured data. If it’s a block quote then it’s copyright problematic (certainly not cc0-pure like wikidata likes to keep things. Longform freetext properties seem to be the opposite of what wikidata’s about, I would have thought. Wittylama (talk) 22:48, 7 February 2020 (UTC)[reply]
      • As the proposed description says "respect others' copyright". It's no more copyright problematic than any other info. Eg Nomenclature (one of the examples) is released under appropriate copyright in its entirety, labels and descriptions alike. I challenge everyone to give examples of datasets where "data" is cc0 but descriptions are not.
      • @Wittylama: I am surprised that you as a GLAM person don't see the value of such a prop for GLAMs.
      • WD has many items that will probably never get a WP page. Such items will be the poorer if one can't record a rich description. Eg CHIN want to add rich descriptions to the 15k Nomenclature objects...
      • Many GLAM projects want to use WD as an integration platform. Eg we plan to import 500 Orthodox icons and enrich data about painters, saints, monasteries etc, see http://rawgit2.com/VladimirAlexiev/my/master/pres/20200130-Wikidata-Icons/Slides.html. But without rich description it makes little sense to describe icons. --Vladimir Alexiev (talk) 19:42, 8 February 2020 (UTC)[reply]
        • I can and do see the value of rich, contextual, nuanced, descriptive information (especially for glams). However, I am saying that paragraph-length Freetext is not structured data, and therefore isn’t within the scope of Wikidata. Moreover, lengthy quotes (such as in the examples given above) are more than trivial because they represent the entire text professionally-written description and therefore are copyrighted information. This is different from information like ‘height’ or ‘year’ or ‘creator’ which are simple facts an therefore non-copyrightable. Thus, this property could only be used when a glam has proactively decided to share ALL fields of their their collection records under CCO - this is not information that can legally be scraped from databases and republished by us unless they’ve released it.
          • @Wittylama: No, you cannot scrape somebody's database just because you believe "simple facts are non-copyrightable". Collections of such facts are very much copyrightable and people pay big bucks to obtain appropriate datasets. Descriptions are no more copyright-problematic than other fields --Vladimir Alexiev (talk) 11:17, 11 February 2020 (UTC)[reply]
    We have had this discussion before with glam concepts like “credit line”. It is very useful and important information about objects in glam collections, BUT “credit lines” are unstructured data/freetext and potentially coyrightable, and therefore we do not [yet] have a solution for how to handle them in wikidata.
    Instead of republishing the full text of the description, could you instead use a property like this to link/reference to where the full description can be found (URL or published catalogue), when such a description exists? Wittylama (talk) 09:12, 9 February 2020 (UTC)[reply]
    @Wittylama: Sure we can and will, but that's no substitute for having a decent description on the item. --Vladimir Alexiev (talk) 11:17, 11 February 2020 (UTC)[reply]
    There's the issue of EU database right given that Bulgaria is an EU country but that's a separate issue from the copyright. ChristianKl13:55, 11 February 2020 (UTC)[reply]

    I see this one will get shot down, so let me explain what will happen:

    • We will import icon descriptions in the existing poor "description" fields (without provenance), because 99% of these will be new WD items.
    • However, we won't be able to import Nomenclature descriptions in the poor "description" fields because many of these are existing WD items, and there's only 1 slot per language, and we can't be sure we won't overwrite information in that slot, no matter how crappy the existing description may be. In fact even for newly created Nomenclature items, we already make poor descriptions eg exterior shutter (Q80794411) has the ancestor path "(Category 01: Built Environment Objects> Building Components> Door & Window Elements> Window Element)" in lieu of a proper description (enough for disambiguating, but not satisfactory). When Nomenclature are ready with their proper editorial description (a big effort on their part), we won't be able to refresh the crappy descriptions in WD items --Vladimir Alexiev (talk) 11:24, 11 February 2020 (UTC)[reply]
      "(Category 01: Built Environment Objects> Building Components> Door & Window Elements> Window Element)" isn't a valid description. Why create it in the first place? --Yair rand (talk) 22:46, 11 February 2020 (UTC)[reply]
      @Yair rand: It serves the purpose to disambiguate and is better than nothing, so why do you think it's invalid? Rather than critique, why didn't YOU make a better description of exterior shutter (Q80794411) if you dislike this one? --Vladimir Alexiev (talk) 15:51, 12 February 2020 (UTC)[reply]
      It's not a valid description under WD:D. I think it would be far preferable to leave it blank, and have it be easily discoverable as a descriptionless item, than to have a non-description taking up the field. I'd recommend deleting all such descriptions. --Yair rand (talk) 06:05, 17 February 2020 (UTC)[reply]

    I just found out that the poor "description" field has a limit of 250 chars. This means we can't import useful descriptions from GLAM datasets like Nomenclature (@Crowjane7:) or icons. Cheers! --Vladimir Alexiev (talk) 13:39, 13 February 2020 (UTC)[reply]

     Not done, no consensus.--GZWDer (talk) 20:31, 18 March 2020 (UTC)[reply]
    Stating that it is quite usual to encounter individuals from a class (web ontology parallel) having a "description" field: even wikidata entities have a "heading-description" that is a short text; it is quite stunning that we cannot find in wikidata a property with "description" as label that would simply be used to precise that an item can have a "textual description" ... painting (Q3305213) have depicts (P180) that basically corresponds to a description, but what about a service (Q7406919), a concept (Q151885)?... maybe a different property can be used: what would be the corresponding property for the heading-description of wikidata entities?
    The advantage of a "description" property would be to be self explanatory and general enough to be widely used among wikidata entities.
    BTW "description" is a very basic property of Thing (the most generic item) in schema.org, cf: https://schema.org/Thing & https://schema.org/description
    NB: a "description" property could logically be a super-property of depicts (P180) which is currently a subproperty of has part(s) (P527) D3fk dev (talk) 14:43, 27 July 2022 (UTC)[reply]
    @D3fk dev: Every item has a multilingual description field at the top level, just like labels and aliases. Why is something more needed? Note also that using a property for this has been discussed here before. ArthurPSmith (talk) 16:25, 27 July 2022 (UTC)[reply]
    The point of Wikidata is having structured descriptions of concepts, not textual ones. Silver hr (talk) 16:45, 27 July 2022 (UTC)[reply]
    @Silver hr: Actually the point here is not to add a description ahead of all item pages of wikidata, as you said the multilingual description is sufficient, but simply to expose as a structured information the fact that some individuals from certain classes (instances of these classes) need a description to be complete entities:
    I exposed as an example previously that service (Q7406919) should be completed with the adding of a "description" property(or similar) because having an instance of a service (Q7406919) that will not have a description of the service proposed will rather be resumed to a title of a service and not a comprehensive service entity: the user of such a service might not understand what will be performed by using the service without a description of the service.... would be the same for many other entities/instances of entities subclasses of concept (Q151885).
    You can make a parallel with the painting (Q3305213) that have depicts (P180)(free text) that basically corresponds to a "description" property of paintings and that is required to make an instance of a painting entity comprehensive... we cannot use depicts (P180) for a service (Q7406919) or any other concept (Q151885)
    On an other point it seems that the multilingual description of each item is currently a simple field but in a more structured way should have logically been a property of each Wikidata entity (Q32753077) or Wikidata item (Q16222597) (as a "description" property?)... but that might implies that each wikidata item page would have been considered as instances of Wikidata entity (Q32753077) or Wikidata item (Q16222597), which might not completely be the case. D3fk dev (talk) 10:10, 28 July 2022 (UTC)[reply]