I think probably a distinction can be made in terms of whether your use case involves exporting items into other ontologies, versus importing items from other ontologies into wikidata. You'll have different issues with granularity in either direction and they may not be entirely symmetrical, so you might actually have to model it in both directions, difficulties of querying aside.
My use case involves creating wikidata items from
citoid items, so I have been thinking of modelling the Zotero/Citation Style Language on wikidata as part of using citoid on Wikidata (which uses the Zotero ontology.) Unlike
schema.org there's no canonical url pointing to different properties, so I'd actually like to create an item for each Zotero / Citoid property and actually store the entire schema itself on wikidata. (This has the additional use case being able to provide documentation of the properties using reasonator as well!)
I've created an example on test wikidata here:
https://test.wikidata.org/wiki/Q173241. Here we have the property publicationTitle, which in citoid/Zotero, has a string value. In wikidata we would want this to point to an item corresponding to the publication so we'd use "published in" property as equivalent. There's also hierarchy modelled here, with websiteTitle being a subclass of publicationTitle:
https://test.wikidata.org/wiki/Q173239 This is a different way of modelling it versus adding an equivalent property to the wikidata property a la
https://www.wikidata.org/wiki/Property:P356. For my use case, this would be the easiest model for querying the properties. But I share Stas's concern here that this could quickly explode the number of items. How many items called "title" do we need, because "title" is a property in a lot of examples?
You can see in my example I made my property and instance of both a citoid property and a zotero property. They mostly overlap, but there are few citoid properties which are not Zotero properties. CSL properties are even trickier. I think if they have the same exact name string and all other properties and equivalencies they can be put in one item but I don't anticipate that happening much with other less similar ontologies.
Not exactly sure what to use for the name of the property to store the string, i.e. "publicationTitle" either - might have to create a new property for that (I checked, Official Name doesn't take "JSON" as a valid language!)
(The other thing is I've now gone down the rabbit hole of thinking about modelly markup and programming languages. In a JSON object there's a limited number of types (Object, string, array, integer etc), and I've had a go of adding that on test wikidata - but it kind of opens up the idea of actually adding in a full model of a programming language which sounds crazy until you consider that we've done basically that with the addition of lexographical data!)
Cheers,
Marielle