Property talk:P1684

From Wikidata
Jump to navigation Jump to search

Documentation

inscription
inscriptions, markings and signatures on an object
Descriptiontext written on an object. Widely used in Commons and in various museum databases. Inscriptions exceeding length limits should probably be stored somewhere else, perhaps in Wikisource.
Representsinscription (Q1640824), epigraph (Q3589144)
Data typeMonolingual text
Domain
According to this template: all sorts of artworks and other material objects
According to statements in the property:
work (Q386724), flag (Q14660), archaeological artifact (Q220659), appliance (Q1183543), memorial stone (Q11734477), physical sign (Q105449313) or content descriptor (Q68183127)
When possible, data should only be stored as statements
Example
According to this template: La Liberté guidant le peuple => Eug. Delacroix 1830, in French
According to statements in the property:
Shugborough inscription (Q7504674) → O U O S V A V V
Arch of Constantine (Q5786) → IMP · CAES · FL · CONSTANTINO · MAXIMOP · F · AUGUSTO · S · P · Q · RQUOD INSTINCTU DIVINITATIS MENTISMAGNITUDINE CUM EXERCITU SUOTAM DE TYRANNO QUAM DE OMNI EIUSFACTIONE UNO TEMPORE IUSTISREM PUBLICAM ULTUS EST ARMISARCUM TRIUMPHIS INSIGNEM DICAVIT
When possible, data should only be stored as statements
Commons example
  • → Wii™
    → Wii™
  • → SHE’S GETTING EXISTENTIAL AGAIN. / IT’S OKAY, I HAVE A SUPER SOAKER.
    → SHE’S GETTING EXISTENTIAL AGAIN. / IT’S OKAY, I HAVE A SUPER SOAKER.
Sourceexternal reference, Wikipedia list article (either infobox or source) (note: this information should be moved to a property statement; use property source website for the property (P1896))
Robot and gadget jobsDeltaBot does the following jobs:
Tracking: usageCategory:Pages using Wikidata property P1684 (Q21037844)
See alsomonogram (P1543), unabbreviated text (P7008)
Lists
  • <search Commons for files with depicts-statement and this property as qualifier>
  • Search Commons for files with property
  • Items with the most statements of this property
  • Count of items by number of statements (chart)
  • Count of items by number of sitelinks (chart)
  • Items with the most identifier properties
  • Items with no other statements
  • Most recently created items
  • Items with novalue claims
  • Items with unknown value claims
  • Usage history (total)
  • Chart by item creation date
  • Database reports/Constraint violations/P1684
  • Map
  • Random list
    • Proposal discussionProposal discussion
    Current uses
    Total73,487
    Main statement71,98598% of uses
    Qualifier1,2581.7% of uses
    Reference2440.3% of uses
    [create Create a translatable help page (preferably in English) for this property to be included here]
    Scope is as main value (Q54828448), as qualifier (Q54828449): the property must be used by specified way only (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P1684#Scope, SPARQL
    Allowed entity types are Wikibase item (Q29934200), Wikibase MediaInfo (Q59712033): the property may only be used on a certain entity type (Help)
    Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
    List of violations of this constraint: Database reports/Constraint violations/P1684#Entity types

    discussion[edit]

    Language indication obligatory, that is not right.[edit]

    When using this property inscription (P1684) in a declaration, a language MUST be given (otherwise the declaration can not be stored). This is not allright, not every inscription has an explicit language.

    As an example: item Q2198126 has an inscription "Art Schnitger 1648 1719", that 's a name and two numbers/years. What to do, here?

    Furthermore there are very many inscriptions have text in two (sometimes even more) languages, e.g.:

    • text in a "local" language with a motto in Latin,
    • inscriptions in bilingual areas.

    Is there a solution for this problem ? --Paulbe (talk) 11:41, 8 October 2015 (UTC)[reply]

    New WMF language codes available: "und", "mis", "zxx", "mul"[edit]

    The following new codes are now available:

    "zxx"
    no linguistic content (Q22282939)
    "mul"
    multiple languages (Q20923490)
    "und"
    undetermined language (Q22282914)
    "mis"
    language without a specific language code (Q22283016)

    Please see phab:T72205 for further information. Thanks to the devs!
    --- Jura 12:57, 26 January 2016 (UTC)[reply]

    They stopped working :(
    --- Jura 13:41, 28 January 2016 (UTC)[reply]

    Linebreaks[edit]

    The datatype monolingualtext doesn't support linebreaks, tabs and other control characters. Some inscriptions are multiline. To understand the meaning of the inscription the linebreaks are important. As a surrogate for the linebreak its possible to use the slash "/"? What do you think?
    --Looniverse (talk) 09:37, 16 July 2018 (UTC)[reply]

    sadface on the fact that there is no update here :(
    Maybe the good old "<br>" from Wikipedia?
    --D-Kuru (talk) 20:36, 23 April 2020 (UTC)[reply]
    +1 --Herzi Pinki (talk) 10:32, 21 November 2020 (UTC)[reply]

    Lexeme property or qualifier[edit]

    Now that we have lexemes it would be nice to link to lexemes if an inscription also has a lexeme item. I would like to link for example from Headquarters of Pensionsversicherungsanstalt (Q57416663) to a lexeme "Pensionsversicherungsanstalt". There are many other buildings with inscriptions that could use a similar property. At the moment I am not sure if that should be a qualifier for inscription (P1684) or used independently. --Tobias1984 (talk) 12:49, 17 October 2018 (UTC)[reply]

    full text search[edit]

    Is it possible to search also for content in property. I tested out Davao City Hall historical marker (Q28937459) string 'bilang gusaling munisipal' and this does not work for me. Regards, Conny (talk) 12:51, 28 March 2019 (UTC).[reply]

    qualifier instance of (P31): replacement with object has role (P3831)[edit]

    As P31 should no longer be used and we have P3831 in the meantime, I made a replacement request at Wikidata:Bot_requests#Change_pq:P31_to_pq:P3831_(for_P1684). --- Jura 14:08, 21 June 2019 (UTC)[reply]

    @Jura: If you change a way data is modeled, please alert tools and projects consuming the data. {{Artwork}} template uses P1684 and looks for P31 to be establish the type. Apparently for last year they were broken. Someone asked me about it and I was rather surprised that the inscriptions were no longer using P31. Just changing the data is only half of the task, changing the codes of all the data consumers is the other half. --Jarekt (talk) 00:30, 25 May 2020 (UTC)[reply]

    Help with modeling inscriptions[edit]

    I could use some assistance/advice on modeling complex inscriptions. I particularly want to make sure that the data can be ported over to the Commons {{Inscription}} template when that process gets automated.

    I am working on 35 hand-annotated proof maps by Christopher Saxton from Lord Burghley's Atlas in the British Library. An example early version of one of these map items is here: Map of Northumberland (Q105816017). This effort is part of our new WikiProject on Early Modern England and Wales.

    I am pinging some people who might be interested in these questions.

    @Jheald, DrThneed, Multichill, Jarekt, Jane023, Zolo:
    @Mike Peel, Spinster:

    Specific questions below. Thanks for your help! - PKM (talk) 21:38, 8 March 2021 (UTC)[reply]

    PKM although Commons {{Inscription}} template was never rewritten in Lua or integrated with Wikidata. Commons {{Artwork}} template does the second best approach and in case of missing value of inscription field and connection to Wikidata, it will translate data found in inscription (P1684) and build one or more {{Inscription}} templates from scratch. You can find the code at c:Module:Wikidata_art line ~ 300. The current code can recognize text inscription (P1684) values with the following qualifiers:
    As for specific requests below I did not check which are supported and which are not. You can test, specific inscritions as shown in tests at c:Module_talk:Wikidata_art/testcases#Inscription. If something is missing I am sure we can add it. --Jarekt (talk) 04:15, 10 March 2021 (UTC)[reply]
    @Jarekt: I hadn’t thought about building the Template:Inscription on the fly - Template:Artwork can do it, then I guess Template:Map could do it in the future. - PKM (talk) 06:28, 10 March 2021 (UTC)[reply]
    Template:Map does not have to wait. Inscription and other tricky property handling is done inside a separate module c:Module:Wikidata_art, so that it can be used by others. It is just a matter or calling it. --Jarekt (talk) 13:49, 10 March 2021 (UTC)[reply]

    Cartouches with text[edit]

    Is this correct for a title in a cartouche?

    - PKM (talk) 21:38, 8 March 2021 (UTC)[reply]

    PKM, cartouche (Q2374398) are supported and title (P1476) are supported but cartouche (Q2374398) and title (P1476) are not supported and will not get i18n. We can add "cartouche with title" to c:Template:Inscription/label and to c:Module:Wikidata_art. --Jarekt (talk) 04:49, 10 March 2021 (UTC)[reply]

    Coats of arms[edit]

    These maps all have the coats of arms of Elizabeth I and of Sir Thomas Seckford, who sponsored the maps, separately, sometimes in a cartouche and sometimes not.

    How can I indicate that these are Royal Arms of England (Q643999) or the arms of Thomas Seckford (Q7793855)? (I'll be using "arms of Thomas Seckford" a lot, so I'd be happy to make an item for them.) - PKM (talk) 21:38, 8 March 2021 (UTC)[reply]

    "no value" is a bit weird, as it suggests that there is no inscription at all. Maybe we should have a different property to mention non-linguistic markings ? The cutoff may sometimes be blurry though... --Zolo (talk) 18:27, 9 March 2021 (UTC)[reply]
    "no value" is strange but better than any other text I can think of. I tried {{inscription |type=coa |position= top right }} on commons and got "Wappen oben rechts" in German. I can call the template with equivalent parameters from Lua. Indicating specific coa would be better but harder to reproduce using c:Template:Inscription --Jarekt (talk) 05:05, 10 March 2021 (UTC)[reply]

    Map scale[edit]

    These maps have a "scale of miles" map scale (Q1914828), usually ornamented with a large pair of compasses (compass (Q103896)). Is this a new "type" of inscription, or something else? How would we model it? - PKM (talk) 21:38, 8 March 2021 (UTC)[reply]

    Compass roses[edit]

    A few maps of the Saxton maps have a compass rose (Q640047). Should this be another type of inscription? - PKM (talk) 21:38, 8 March 2021 (UTC)[reply]

    I would model this just like COA. --Jarekt (talk) 05:11, 10 March 2021 (UTC)[reply]

    Direction banners[edit]

    The example map has scrolls or banners on all four sides indicating the cardinal directions. Should these be called "cartouches"? I'd prefer a new type "banner" AKA "scroll" = "map element in the shape of a folded or curled ribbon, containing text", but I am open to recommendations here. - PKM (talk) 21:38, 8 March 2021 (UTC)[reply]

    Inscription mentions[edit]

    I see there has been discussion above re using inscription mentions (P6568) as a qualifier on "Inscription". I'd like to do this. I see that it has been used this way despite the property restrictions (see sickle sword (Q29384403)). I prefer it to main subject (P921) (as used at Victory Banner (Q72298)), which also causes a constraint violation. - PKM (talk) 21:38, 8 March 2021 (UTC)[reply]

    Agree. To me, "main subjet" and "inscription mentions" are sowewhat different. e.g. an inscription saying "portrait of John Doe" could have "main subjet>name of model" and "inscription mention John Doe". --Zolo (talk) 18:24, 9 March 2021 (UTC)[reply]

    And general thoughts[edit]

    Using "inscriptions" for image-like items such as cartouches and coats of arms is a long-standing practice in the Commons templates, but it seems like replicating that within Wikidata's "inscription" statement is preventing us from using additional qualifiers where they would be helpful. Perhaps there's a better way to approach this than I have thought of? - PKM (talk) 22:18, 8 March 2021 (UTC)[reply]

    Maybe we should reserve inscription (P1684) for text based inscriptions and create new property for non graphic ones. This property would take wikidata item. Maybe "Graphical elements used", "inscribed graphical elements", etc. Those can include: compass roses, map scale, legend/map key, North arrow, etc. for maps. Coa, graphic (non-text) monograms, seals, stamps, pottery marks, watermarks, reign mark on Chinese ceramics (Q98877418), etc. --Jarekt (talk) 05:31, 10 March 2021 (UTC)[reply]
    Yes! - PKM (talk) 06:30, 10 March 2021 (UTC)[reply]

    Discussion[edit]

    • @PKM: Thanks for opening this up. I think there are some very useful questions you raise, that also lead to some wider issues of modelling on SDC. IMO these maps make an excellent test-case to see just how much detailed information about an object we can represent in SDC/wikidata, and to reveal choices that we ought to think about.
    For me this property P1684 is fundamentally about text. I think it would be useful to keep text as its clear focus. That maybe can get bent a little, as it may be hard to represent the text of some inscriptions -- we can probably just about manage hieroglyphs, using unicode; but eg what about a goldsmith's en:Hallmark#UK on a piece of silver, where the 'inscription' may include a leopard's head symbol to indicate London, a letter in a particular style to indicate the year, a purity code, and a maker's mark that may be another symbol. I think inscription (P1684) could just about be stretched to handle that, particularly with qualifiers to indicate the meaning of the inscription, eg the year represented, the assay office represented, the maker represented. (Qualifier inscription mentions (P6568) seems to me a good step in this direction, and like PKM I agree it should be approved for general use).
    But I get uncomfortable about going much beyond that. The name of this property is "inscription", not "ornament". When it comes to things like cartouche (Q2374398) or coat of arms (Q14659), it seems to me that the role of P1684 is to indicate the text that such objects contain. P1684 is IMO not the right first-line general way to say that such things (or other elements from c:Category:Map elements) exist within the image. The right way to do that (IMO) would be to say <File>has part(s) (P527)cartouche (Q2374398) or <File>has part(s) (P527)coat of arms (Q14659). That way one can attach qualifiers, such as relative position within image (P2677) or the more detailed region within image (P8276) to say where in the image the object is (distinct from the inscription within it); one can use qualifiers like of (P642) to say who the coat of arms belongs to; one can say that the cartouche has part(s) (P527) the coat of arms, etc.
    So in respect of the detailed questions above, I don't think that inscription (P1684) is probably the right first-choice way for almost any of the above. Some more detailed thoughts to follow. Jheald (talk) 12:45, 9 March 2021 (UTC)[reply]
    Follow ups.
    (1) Current usage of P1684. Query https://w.wiki/34z2 seems to me quite useful, to give current values of object has role (P3831) qualifiers on inscription (P1684) with examples of their use. Also this query to see what other qualifiers are typically in use. (Or more specifically, how they are in use on wikidata items, since I wasn't querying SDC,) A few general observations (not necessarily related to PKM's questions):
    Overall it seems to me that inscription (P1684) has a clear purpose, for text, and seems to be doing it well. Jheald (talk) 13:12, 9 March 2021 (UTC)[reply]
    (2) Not all text in an image is necessarily described by inscription (P1684). In Wikidata:Property proposal/named place on map, it is proposed that a object named as (P1932) qualifier be used to indicate the text used to label a particular place on a map. Similarly identified in image by (P7380) is available as a qualifer to indicate identifying letters or numbers. (In each case a new property "label location within image" might be a useful addition, to indicate where in the image the text, number or letter occurs). In the context of maps and prints the same object named as (P1932) / "label location" combination might be used as qualifiers on title (P1476), creator (P170), contributor to the creative work or subject (P767) to indicate where and how those statements appear in the typical credit-line of a print, rather than using P1684. For an image like https://www.flickr.com/photos/britishlibrary/50263236958 one might even use the same object named as (P1932) / "label location" combination as a qualifier on depicts (P180), to record the label used for each of the little views. P1684 won't be used for everything. Jheald (talk) 13:35, 9 March 2021 (UTC)[reply]
    (3) Something partly underlying the original questions I think (and also (2) immediately above) is the thought: to what extent can we get everything to fit within one statement? So in the original question, if we have a statement for the inscription within a cartouche, can we also get that statement to carry the water for the existence of the cartouche? Or, in (2) immediately above, if we have a statement giving what the little mini-view depicts, can we also get that statement to carry the water for how the depiction is labelled, and where the label can be found on the image? Being able to put everything in one statement is a very economical way in SDC/wikibase to show different things are related.
    But the approach has limitations, because you cannot put a qualifier on a qualifier. If you want to use qualifiers, they have to be on a main statement. And this creates intense limitations. As noted above, there are natural qualifiers for inscriptions, and natural qualifers for cartouches and coats-of-arms. Kept apart there is real clarity. The more you jam onto one item, the more that clarity gets lost. And there are qualifiers like relative position within image (P2677) you may want to apply to the cartouche and the coat of arms and the inscription. How can you do that if all three are jammed into the one statement? In contrast to Cinderella's sisters, it seems to me that we should realise that there is a limit to how much we could or should try to jam into the one single glass slipper. If the hacksaw and the blood start appearing, because we're chopping things off to make everything fit, that's probably a sign that the modelling approach has gone as far as it can.
    This realisation originally struck me forcefully at Wikimania in Stockholm, in connection with another map-modelling question: what to do if a printed sheet on Commons contains multiple maps, for example one or more main maps, plus a number of inset-maps, each potentially with a number of things we might like to represent as main statements with their own qualifiers -- eg title, scale, derivation, various kinds of georeferencing information. I kept trying it round various different ways -- what could I make as a main statement, how much of the rest could I then hang off that main statement as qualifiers -- but every way round, information was getting lost, because we couldn't have qualifiers on qualifiers. I had hit the limit of the all-in-one-statement model.
    There is an answer, I think, that might be the way forward in these cases of particular complexity, viz: named image regions. Just as we can give references names using <ref name=...>, so I could imagine giving parts of an image their own identifier strings by which they could then be referenced, via a qualifier like image region has identifier = ... on a has part(s) (P527) or depicts (P180) statement. Then in other statements one could use a matching qualifier applies to identified part = ... (synonym: contained within identified part), to indicate precisely what they apply to.
    With such a structure one could represent a hierarchical structure of information about an image, to arbitrary depth, something we probably need if would like to be able to round-trip IIIF annotations in their full generality. For map-sheets it would mean one could identify regions as "inset map 1", "inset map 2", "inset map 3", etc, and then say that a particular statement applied to that particular inset map. For cartouches etc, it would mean that one would be able to have different statements establishing the cartouche, the coat of arms, the inscription etc; but then be able to relate them together with qualifiers saying that this inscription and this coat-of-arms relate to this cartouche, and so forth, in a structure that ultimately will be not so strained, but more easy and more relaxed. Most files won't need this, but for those that do I think such a facility could cut through a lot of problems for us. Jheald (talk) 15:04, 9 March 2021 (UTC)[reply]
    • I believe we should model things in Wikidata in a way that makes sense within our ontology, and so I am also inclined to restrict "inscription" in Wikidata to text items. I would also like to keep "depicts" for items depicted in a work, not added onto them as a layer of metadata. Perhaps what is needed is a new property has decorative element, with objects restricted to "symbol, design element, motif, map element, coat of arms" that could take part of (P361) or shown with features (P1354). Then we might have:
    • <has decorative element> "map scale" > <shown with features> "pair of compasses (motif)"
    • <has decorative element> "coat of arms" > <represents> "Dudley family"
    • <has decorative element> "cartouche" > <has part> "Royal Arms of England", <has part> "inscription", <has part> "date"
    If we have a new property, it should be fairly easy for the Commons template to pick the information up and map it as an "inscription type" on Commons. - PKM (talk) 19:28, 9 March 2021 (UTC)[reply]
    @Zolo, Jarekt: so it sounds like we're thinking the same way - how about has graphical element? I wasn’t entirely happy with “has decorative element” - too easily confused with has pattern (P5422). I can write up a property proposal. - PKM (talk) 06:44, 10 March 2021 (UTC)[reply]
    New property proposed: Wikidata:Property proposal/Creative work#has graphical element. - PKM (talk) 21:21, 10 March 2021 (UTC)[reply]

    Related property approved[edit]

    @Jarekt, Zolo: the new property has graphical element (P9344) has been approved. I’ve used it at Q106089814#P9344. Comments on this usage appreciated! - PKM (talk) 01:03, 22 March 2021 (UTC)[reply]

    Thanks, I have lest a message at Property talk:P9344. -Zolo (talk) 11:23, 22 March 2021 (UTC)[reply]

    Engraved credit = signature?[edit]

    @Zolo, Jarekt: I have engravings with inscriptions in the form "Augustinus Ryther Anglus sculpsit" and "Christophorus Saxton descripsit", should these inscriptions be type = "signature" or something else? - PKM (talk) 21:44, 22 March 2021 (UTC)[reply]

    @Jheald: FYI. - PKM (talk) 21:46, 22 March 2021 (UTC)[reply]
    Is it what MARC cataloguing calls a "responsibility statement" ? (Or perhaps that phrase is limited to a part of the printed title of work). I would have thought that a 'signature' has to be hand-written by the signer, as opposed to an attribution line on a print. Jheald (talk) 22:14, 22 March 2021 (UTC)[reply]
    I agree "signature" is wrong, but I am not sure what to use instead (if anything). - PKM (talk) 22:21, 22 March 2021 (UTC)[reply]
    @Jheald: I note we have two items for "signature": signature (Q188675): handwritten mark made as a proof of identity and intent and signature (Q1373131): mark of the creator on a work to identify themselves as such (name, initials, monogram) with aliases sculpsit, fecit, pinxit, etc. We also have an item for sculpsit (Q105839764), from PLwiki. signature (Q1373131): mark of the creator on a work to identify themselves as such (name, initials, monogram) seems like a good choice? - PKM (talk) 22:39, 22 March 2021 (UTC)[reply]
    ...and c:Module:Wikidata art knows about both Q items for "signature" and renders them both as type=signature, so I think that solves it. - PKM (talk) 23:11, 22 March 2021 (UTC)[reply]
    PKM Funny I was just cleaning up: sculpsit (Q105839764), pinxit (Q6477393), and delineavit (Q9205718), items. Those were used on engravings to specify the artist that did the engraving ( sculpsit (Q105839764) ) Vs. artist whose painting or drawing was engraved pinxit (Q6477393) & delineavit (Q9205718). I would use the broader signature (Q1373131) in this case. --Jarekt (talk) 01:00, 23 March 2021 (UTC)[reply]
    @Jarekt: I should add an item for “descripsit”, used the same way for cartographers. I’ll use signature (Q1373131) as you suggest. - PKM (talk) 19:17, 23 March 2021 (UTC)[reply]
    We now have descripsit (Q106142500). - PKM (talk) 19:42, 23 March 2021 (UTC)[reply]

    Allow qualifier "applies to part"?[edit]

    Per the property constraints, applies to part (P518) is not an allowed qualifier. It is used 3123 times and is handled in the module c:Module:Wikidata art. Any objection to adding this to the allowed qualifiers? [edited] - PKM (talk) 22:20, 22 March 2021 (UTC)[reply]

    I did not notice it was not allowed, as I have seen many people use it. Yes we should add it. --Jarekt (talk) 01:03, 23 March 2021 (UTC)[reply]
    YesY Added applies to part (P518) as allowed qualifier. - PKM (talk) 19:44, 23 March 2021 (UTC)[reply]

    Allowed qualifier[edit]

    Please allow qualifier script directionality (P1406) and typeface/font used (P2739). --Takashi KOIKE (talk) 06:29, 1 July 2021 (UTC)[reply]

    Looks like they are allowed now at least. --Marsupium (talk) 23:11, 17 December 2023 (UTC)[reply]
    Retrieved from "https://www.wikidata.org/w/index.php?title=Property_talk:P1684&oldid=2031867618"