Wikidata:Property proposal/Contains

contains

Originally proposed at Wikidata:Property proposal/Generic

   Done: contains (P4330) (Talk and documentation)

Description	physical item or substance located within this item as a container
Data type	Item
Domain	instances of Reliquary (Q137969) (and any circumstance where something is “inside of” a Q item.)
Example	Reliquary with the Tooth of Saint John the Baptist (Q24946506) → CONTAINS → tooth (Q553) → of (P642) → John the Baptist (Q40662)

After quite some extensive discussion on Wikidata:Project chat#Reliquaries on how to best model the question of “what is inside a reliquary” I believe that a new “Contains” property is the consensus outcome for formal proposal. We’ve talked about many potential methods using existing properties (including varioations on “has part”, “material used” and “commemorates”) but none is quite sufficient. Over on the Wikidata+GLAM Facebook group we’ve also been thinking of other use-cases for such a property from different fields (examples include fabrics, rocket payloads, and other storage/transport systems).[1]

Wittylama (talk) 15:06, 20 September 2017 (UTC)

Discussion

 Support Also good for buildings that change purpose for organizations that inhabit them. Jane023 (talk) 15:48, 20 September 2017 (UTC)

 Support should this be a subproperty of has part(s) (P527)? I agree this is a generally useful property, thanks for proposing it. ArthurPSmith (talk) 18:10, 20 September 2017 (UTC)

I’m not sure what you mean by “subproperty” (this is a term I’m not familiar with in the Wikidata context), but we discussed “has part” quite extensively on the Project Chat discussion I linked above. It was actually my first proposal. However, ultimately, Has Part is not really appropriate because the item being contained is a ‘’separate thing’’ to the container (in this case “relic” contained by a “reliquary”) whereas “has part” refers to the ‘’parts of the container’’ itself e.g. a embedded jewels, lid, handles, etc. Wittylama (talk) 19:23, 20 September 2017 (UTC)

No this should not be a sub-property of "has part". In the example, the reliquary is the container, and the relic is not a part of its container, but is contained within the container. Hope this makes it clearer. Jane023 (talk) 20:06, 20 September 2017 (UTC)

part of (P361) is used in a very general and subsumes many properties such as affiliation (P1416), carries (P2505), and member of (P463) so a new "contains" property would definitely be a subproperty! -- JakobVoss (talk) 07:15, 21 September 2017 (UTC)

 Support Seems like a good proposal to me, could have many applications.--Pharos (talk) 19:35, 20 September 2017 (UTC)

 Neutral could you give more examples from other domains? I'd object a property only designed for reliquaries but if there are more use cases it makes sense. -- JakobVoss (talk) 07:15, 21 September 2017 (UTC)

Agreed, that if it is only going to be useful for reliquaries then we might as well propose some really specific property for JUST that purpose. But it feels instinctively that this would be a dumb idea and that there must be diverse structured data uses for the concept of “x thing encapsulates y thing”! See the Facebook discussion I linked in the nomination for some examples that have been suggested from different fields - fashion materials, satellite launches, food storage... Wittylama (talk) 12:45, 21 September 2017 (UTC)

I think this property needs a clear definition which does not overlap with existing properties such as has part(s) (P527), made from material (P186), has part(s) of the class (P2670), location (P276), located in/on physical feature (P706), residence (P551), or headquarters location (P159), but is also not restricted to such a limited domain as reliquaries. Perhaps it should be limited to these situations: The subject is a physical, non-geographic, tangible object which physically encapsulates/surrounds a separate distinct physical object which is not part of the subject. It should not be used for transient statuses (no "this elevator > contain > this person, point in time: Jan XX 20XX" simply because they're using it to get to the next floor), nor for place of burial (P119), which... hmmm...
This is actually quite messy, now that I think on it. The original proposed application of this property was for reliquaries, but many of those should probably use place of burial (P119) directly, with qualifiers. (P119 specifically allows uses for parts of bodies.) The remaining uses still have no dedicated property, and the lack of a property matching with the concept of "containing" is still an important conceptual gap, but splitting the topic across two properties for human remains and everything else seems less than ideal. --Yair rand (talk) 22:59, 26 September 2017 (UTC)

Yair rand a reliquary doesn't always contain human remains, there are other types of sacred objects involved. I think this property is useful, for example we might want to say that Well of Life (Q12751961) 'contains' water (Q283). Of course in most cases the object inside is the notable thing and the right relationship is to use location (P276) or some variant of that in the inverse direction. ArthurPSmith (talk) 19:52, 27 September 2017 (UTC)

I agree that it would be useful to have a "contains" property, but it should be appropriately restricted to not be mixed up with other properties. Unless place of burial (P119) is changed so that it doesn't allow use for reliquaries, this property should not be used for the same relationships. Unnecessary inverses are Bad, especially if ambiguous. No relationship should be simultaneously/redundantly indicated by both P276 and "contains". --Yair rand (talk) 22:00, 27 September 2017 (UTC)

The way I have come to understand this now is that it should be used in the case where the item is a container of some other item or items, and perhaps in normal circumstances you would just use "has part" to indicate that it contains something, but in this case you want to use "has part" to describe the item itself, and not the items it contains. Reliquaries are one case, seeing as how the devotional objects may have more than one container over time (with disputed provenance etc). The point of having this property is to separate the "contained item or items" from the "container item" in a more meaningful way than is currently possible with "has part/part of". Another case could possibly be special purpose-built gallery halls or display units that have since been emptied as the contents were sold or moved etc. Jane023 (talk) 11:27, 28 September 2017 (UTC)

• I've added an English description; we should also probably have usage instructions as implied by Yair rand - how about "Use only when a more specific property is not suitable; the inverse (P276 - location) should be used if the value (contained) item is a unique physical object in itself. Has part (P527) should be used if the value item is an integral part of the container." ArthurPSmith (talk) 17:16, 28 September 2017 (UTC)

 Support makes sense, and agree that something contained in a vessel should not be said to be its part. Ijon (talk) 16:40, 30 September 2017 (UTC)

•  Support ديفيد عادل وهبة خليل 2 (talk) 21:00, 1 October 2017 (UTC)

• @Wittylama, Jane023, JakobVoss: @Pharos, Yair rand, Ijon, ديفيد عادل وهبة خليل 2:  Done ArthurPSmith (talk) 18:22, 11 October 2017 (UTC)