“This property generalises the notions of “copy of” and “similar to” into a dynamic, asymmetric relationship, where the domain expresses the derivative, if such a direction can be established. Otherwise, the relationship is symmetric. It is a short-cut of P15 was influenced by (influenced) in a creation or production, if such a reason for the similarity can be verified. Moreover it expresses similarity in cases that can be stated between two objects only, without historical knowledge about its reasons.”

How else should those bold sections be interpreted?

3. P130_shows_features_of is not vaguer than P62_depicts. P130 means “a derivation” or “copy after” etc etc. It’s used for artistic derived works, not for photos. Scope note says “It is a short-cut of P15 was influenced by in a creation or production”: which means “the production of the photo was Influenced by the original object”, but Influenced is too weak interpretation for this situation.

Furthermore, I think you said some instances could be “a document about the original object” and similar, in which case there’s are no “shared features” at all.

If the relations are directed (X is later object –related to–> Y is the original object), you have this option:
X P128_carries X-concept.
X-concept a E73_Information_Object;
P67_refers_to Y.

P67_refers_to is a weak relation that commits neither to strong aboutness (P129 is about), nor to visual representation (depiction)

And thanks for your comments on the CRM modelling; they are much appreciated.

To answer your numbered points:

1. Unfortunately the museum’s API doesn’t offer me “artworks” with “titles” – only “objects” (which may or may not be artworks). I have used the more general property because although a more specific property is better for artworks, I don’t have an automated means to determine whether they were in fact artworks, and not e.g. horseshoes or chamber-pots. That’s why I chose to do it that way, at least, though it’s possible I’ve missed some clues provided by the API that would enable me to use a more precise class. When I get a chance I would like to go back and refine the model, but this is just a “proof of concept” (Museum Victoria are not a paying client) so I haven’t felt much of a call to bring it to a “production” level of readiness. I think if it were a real project, some of these modelling issues would be best addressed by improving their underlying API; I know for a fact that in some places the underlying data in their CMS is richer than the API exposes (i.e. the API itself is a semantic bottleneck).

2. A definite bug – thank you! I have logged an issue and I will fix it shortly. https://github.com/Conal-Tuohy/XProc-Z/issues/13

3. The problem here again (I had hoped to make it clear in the section entitled “Articles, Items and their relationships”) is that the museum’s API is not specific enough about the objects to allow the XSLT to make the assertion that a photo depicts another object. It’s easy enough for a human to tell, by reading the textual description, that this is a photo of a house, and that this other object is a photo of the same house, but those facts are not expressed in a machine-actionable way. All I have to go on is that some objects are “related”. Hence I’ve felt constrained to assert something much vaguer than the notion of “depiction”, namely that the objects are merely similar, using P130_shows_features_of. I feel a bit uncomfortable even with that, given that it’s only based on an assertion by the museum’s API that the objects are “related”. However, from the example cases I looked at, it certainly seemed to be the case that “related” objects showed some similarity. When you say that using P130_shows_features_of is “wrong”, do you just mean that it is overly general (which I would accept it is, of necessity), or are you saying that it’s actually false to fact? If the latter, could you explain why you think that?