Open main menu

Wikidata:Property proposal/associated with

associated withEdit

Return to Wikidata:Property proposal/Generic

   Under discussion
DescriptionUsed to describe a generic association of one item/concept with another, where we don't have a more specific property available
Data typeItem
Example 1Christmas cake (Q556060)Christmas (Q19809) (qualifier subject has role (P2868) - "food associated with the festival")
Example 2We Are the Champions / We Will Rock You (Q66008229)News of the World (Q309021) (qualifier subject has role (P2868) - "single taken from this album")
Example 3Handbuch zum Evangelischen Gesangbuch (Q53631328)Evangelisches Gesangbuch (Q1381294) (qualifier subject has role (P2868) - "de:Kommentarwerk"/"en:Commentaries related to the work") Evangelisches Gesangbuch (Q1381294)Handbuch zum Evangelischen Gesangbuch (Q53631328) (qualifier object has role (P3831) - "de:Kommentarwerk"/"en:Commentaries related to the work")
Example 4Söderala church parish (Q10688470)Söderala parish (Q10688474) (qualifier subject has role (P2868) - "administrative parish associated with, but not the same as, a religious parish")
Example 5Reading (Q60578270)Reading (Q7300456) (qualifier subject has role (P2868) - "constituency with the same name but different boundaries")
Example 6King Arthur (Q45792)Eildon Hill (Q3049397) (qualifier subject has role (P2868) - "legendary burial place")
Example 7mangalsutra (Q2767663)marital status (Q11920938) (qualifier subject has role (P2868) - "object used to signify")
Planned useWill implement for administrative area relationships to begin with
See alsoinspired by (P941), used by (P1535), based on (P144), influenced by (P737), different from (P1889), etc


This is intended to be used to describe some way in which two items are related to each other, but where there isn't an existing property. The number of potential ways that something can be related/connected to another concept is very large. We have properties for many types of relationship (eg inspired by (P941), used by (P1535) or based on (P144)) but we are unlikely ever to create properties for all the ones we want to describe - some will be very specialised and only need to be used a few times.

My thought is that we can create a generic property to link two items together, with a mandatory qualifier to specify what exactly that relationship is (I've suggested subject has role (P2868), but perhaps a new qualifier property would be needed). The values would be items created to describe that specific form of relationship, allowing for queries. This is similar to relative (P1038)/type of kinship (P1039), which we use where one of the standard family properties like father (P22) can't cover the specific relationship.

Thanks to Moebeus & Salgo60 for some of the examples - see svwp and phab for more notes on parishes. Andrew Gray (talk) 14:43, 20 August 2019 (UTC)


  •   Strong support Nice! Moebeus (talk) 14:48, 20 August 2019 (UTC)
  •   Support Ainali (talk) 14:54, 20 August 2019 (UTC)
  •   Comment it seems to me that we already have a more specific properties for some of the samples above, notably "significant place", "different from", "main subject". --- Jura 15:04, 20 August 2019 (UTC)
  • @Jura1: Good catch. I think there are certainly some overlaps - #6 would certainly fit nicely for "significant place", which I had forgotten was a property! And agree that "main subject" could work for #3 (perhaps with a qualifier to say "is a commentary" rather than any other kind of critical work). But some of the others definitely don't seem to fit in existing properties - eg #1, #2 or #7.
For #4/#5, fuzzy place relationships, using "different from" seems a bit awkward - I can see that it's a possibility, but it doesn't feel like quite the right relationship. It could be that the two items we want to connect aren't really confused by people, and the property description implies that they are. Andrew Gray (talk) 16:18, 20 August 2019 (UTC)
Replacing "main subject" with this seems like a terrible idea. I wonder if there isn't the risk of more similar lapses.
Depending on the names, I think you could have both "significant place" and "different from". We also have "facet of" which overlaps with this. For properties there is "see also", but for items, I vaguely recall that this wasn't thought of being a good idea. --- Jura 17:31, 20 August 2019 (UTC)
I think there are a lot of properties that overlap with this in various ways - in which case we should definitely use those properties. The idea here is to have a fallback option for when those don't work. Salgo60 - you suggested the Kommentarwerk example - is there a reason you thought "main subject" wouldn't work there? I think Jura is right that for that particular case, "main subject" seems more appropriate. Andrew Gray (talk) 18:14, 20 August 2019 (UTC)
  •   Strong support - Salgo60 (talk) 17:08, 20 August 2019 (UTC)
  •   Support Useful generic property to have. Jheald (talk) 17:21, 20 August 2019 (UTC)
  •   Support I've long wondered why we don't have an item equivalent of see also (P1659) (which is for properties). But of course this should be limited only to the cases where there ISN"T an existing property that fits the relationship. ArthurPSmith (talk) 17:34, 20 August 2019 (UTC)
  • Hard solid oppose per previous objections. Propose the properties that we should have in our ontology. --Izno (talk) 19:05, 20 August 2019 (UTC)
  •   Support. If it turns out that we have (or later add) a more specific property, one can always update the item, but IMHO it’s good to be able to capture the relationship. - PKM (talk) 20:10, 20 August 2019 (UTC)
  •   Oppose. Not sure about this. Existing properties such as facet of (P1269) are probably fine enough. Thierry Caro (talk) 22:43, 20 August 2019 (UTC)
  •   Oppose I that case this is really a totally unspecified relationship, this will discourage people to propose properties if there is an alternate solution, and the qualifier to precise the relationship is an open gate for nonsense. Proposing a property is hard, creating an item or misusing one existing in a meaninless cryptic sense is really easy. We’ll end up with a mess. author  TomT0m / talk page 06:21, 21 August 2019 (UTC)
I'll note that this exact argument, only in reverse, is used a lot when shooting down proposals for narrower properties. "We don't need this, we have a less specific property, just use qualifiers to specify it". The way I look at it, it's useful to have a kind of generic "supra-property" like this and use it when modelling: when and if we see a pattern emerge and there is significant volume, it'll be much easier to then propose something more specific and separate out the relevant property/item pairs, rather than starting with a property that is very/overly specific and that ends up being seldom used. There are quite a few of those. Moebeus (talk) 11:25, 21 August 2019 (UTC)
@Moebeus: I don’t dislike generic properties if they make sense on their own. For example instance of (P31) and subclass of (P279) are widely used on ontologies outside of Wikidata and Help:TomT0m/Classification can be well defined. This however needs carefulness. In such cases it can be counter productive to create to specific properties that are essentially the same relationships, but for two kinds of more specific items, this creates dispertion, a discrepancy of practices and models for the same thing. However, in this case, the exact same criticism as « two many properties and different ways to the same stuffs » is . Such a property is totally unspecified, and the probable usecase will be « OK, so I’ve this problem … so what do I do ? Oh, I have an excellent idea ! I’ll use the « relationship property with this qualifier ». And on another item, antother person on a similar case « Oh, I have an excellent idea, I’ll use the relationship property with that combined with that other qualifier ». Except there is no guarantee that a pattern will emerge or that the use will be consistent for similar cases, we already have such problems with current properties sometimes. People do something as they think it’s a good idea but it’s not always easy to decipher what their idea was in the first place. I think that models should be discussed at least a little bit. If their is a usecase, we should be able to find a not to bad solution and document it at least a bit. Such a generic property would in my opinion would have the same problems than too much specific one : too much solutions to express the same thing. So it’s not really a suprise that the argument is reversed, the solution is probably an equilibrium between the two, a compromise between regularity and flexibility/expressiveness. author  TomT0m / talk page 11:45, 21 August 2019 (UTC)
  •   Strong oppose The fact that example were proposed that can already be handeled with existing properties suggests the property would actually used in situations where our existing properties can already handel the situation. ChristianKl❫ 07:10, 21 August 2019 (UTC)
  •   Oppose, per above and earlier arguments. --Yair rand (talk) 07:48, 21 August 2019 (UTC)
  •   Oppose per the above. NMaia (talk) 21:44, 21 August 2019 (UTC)
  •   Oppose I agree many of the examples are inappropriate since there is a more specific prop.
    •   Support To all naysayers: how do you justify the existence of see also (P1659)? BTW, despite its definition, it's used to relate not only props but also categories. Eg route map (P15) is related to Category:Pages using Wikidata property P15 (Q28039620) and Q55283072
    •   Support The fact that dc:relation and rdfs:seeAlso are some of the oldest props on the semantic web should tell us something
    •   Support Quite often in source databases you have such kinds of relations, with no additional info about the nature of the relation. Isn't it better to capture the link, rather than dismiss it as unspecific? --Vladimir Alexiev (talk) 13:19, 22 August 2019 (UTC)
      • If the goal is to import data that's already tagged with dc:relation or rdfs:seeAlso, why do you support a property that has neither of those names for it but a quite different one? If the goal is to copy data from an existing relation, then naming the same relation differently should be justified. ChristianKl❫ 17:40, 22 August 2019 (UTC)
      • Can you provide examples of data sets that use either that you would want to import into Wikidata? ChristianKl❫ 17:46, 22 August 2019 (UTC)
    • It does seem that see also (P1659) gets used currently in a constraint violating way. I don't think that needs justification, it rather needs a removal of the constraint violating uses. ChristianKl❫ 17:47, 22 August 2019 (UTC)
  •   Rename. It's not a property, but a stub. It could be
  • named as proposed to be associated with or short to relate to
  • described as choose a suitable existing property instead of this stub or propose a new one at WD:PP
  • provided with restriction forbidding the stub if a real property already associates this two elements.
This tool would prevent us from semantical straining of property just because there's yet no suitable one.
Anticipated flood of such stubs can be held back by forbidding two stubs, which
  • associate an element with two R-related elements
  • or the other way round which associate two R elements with the same third element.
Where R stands for C* or C*+I or P*, C for subclass of (P279), * for Transitive closure (Q1501387), + for function composition (Q244761), I for instance of (P31) and P for part of (P361).
Abc82 (talk) 08:48, 25 August 2019 (UTC)
  •   Comment I just a few minutes ago ran into a situation where this property (at least as a temporary measure) would have helped - how does one relate IOPS (Q539454) to FLOPS (Q188768)? Neither one have many regular statements, but they are certainly "related" as both being measures of (different aspects of) computer performance. I couldn't think of anything to do, and so the two items remain unconnected. I don't think this is a helpful situation. If people over-use this sort of generic property in certain domains, at least it allows us to do WDQS queries to find such cases and fix them. Without this property we make improving Wikidata harder. ArthurPSmith (talk) 17:36, 27 August 2019 (UTC)
    • When I see that example the first thing I see is that IOPS (Q539454) lacks P31/P279. If this property would get you to use it instead of doing the work the item actually needs which is to start with P31/P279, I would see that as a negative outcome. It seems to me like the shared relationship between might be that they should have a P31 or P279. ChristianKl❫ 20:12, 27 August 2019 (UTC)
      • @ChristianKl: I don't quite follow what you are saying here. I added a P31 for IOPS (Q539454) (the same as the one for FLOPS (Q188768) but that leaves them only extremely loosely related. Did you have something else in mind? ArthurPSmith (talk) 18:35, 28 August 2019 (UTC)
        • One of them is a measurement harddisks and RAM of a computer while the other one is a measurement for CPU/GPUs. The way they are related is that both are measures of computer performance. If you want to capture that information the straightforward way would be to create an item called "measure of computer performance" and use it as the class for both of those items. If you see another relationship between the two that isn't about how both are measures of computer perfomance saying that they have a relationship with each other isn't helpful when the relationship isn't specified. ChristianKl❫ 09:17, 29 August 2019 (UTC)
          • I really don't follow this "instead of doing the work the item actually needs" argument. That's a very subjective measure, and in this case my first reaction was not to do anything at all. Then any other editor who runs across this would have the same burden before any action could be taken. Why do we want to make life more difficult for our editors here? ArthurPSmith (talk) 18:03, 29 August 2019 (UTC)
            • @ArthurPSmith: I don't think "define the nature of the relationship between the two entities" as a requirement for adding a relationship between them a "very subjective measure". If people are generally encouraged to add statements about the fact that two items relate to each other without doing the work of thinking about how they are related that results in messy data.
If two people differ about modelling decisions specifity helps to have a productive discussions. Discussions about whether or not the heart is associated with the stomach seem much more subjective in nature and much more unproductive. ChristianKl❫ 09:39, 16 September 2019 (UTC)
  •   Comment We can also create a template to maintain associations on the discussion page. How could it appear on the main page of an element? -- Abc82 (talk) 07:44, 6 September 2019 (UTC)
    • Actually I like that idea - a "see also" template for items? Item discussion pages are underused, so I think this would be a good idea. ArthurPSmith (talk) 17:32, 6 September 2019 (UTC)
      • Agree discussions pages are underused but for Swedish Adminitrative parishes I would like to have something that can be used with SPARQL (see T201074 - Salgo60 (talk) 10:38, 14 September 2019 (UTC)
  • We can also restrict the property to have no more then one statement for an element and use list values as qualifiers (Q23766486) when associations are many. Bots can gather multiples, uncover single element lists and remove empty as well as duplicates. -- Abc82 (talk) 07:56 19 September 2019 (UTC), 01:49 20 September 2019 (UTC)