The primary focus of this experimental work is to test out the network architecture (i.e. a transforming proxy) rather than to produce a “production quality” expression of Museum Victoria’s dataset. However, I do intend to continue revising the modelling, mostly to incorporate more of the Museum Victoria data in the RDF representation, and of course to refine the modelling I’ve done so far and correct any errors. So I’m very grateful for your comments on the CRM mapping and for any further ideas you might care to contribute, whether by commenting here or by logging an issue or pull request on the GitHub repository. I’ve taken some useful advice from Richard Light on the CRM-sig mailing list too, and I expect to be asking for more as I go.

I’ve already made a change to fix the typo in P70_documents and to simplify the expression of P3_has_note.

EDIT: I’ve added a couple of subproperties of P3_has_note to accommodate the various “note-like” properties in the MV data, and I suspect I will need to add several more as I go.

Your comment about the P130_shows_features_of predicate is not such a straightforward issue, though. My reading of the scope note is that it may validly be applied not only to scenarios involving copying, but also to cases in which items have similar features without one necessarily being a copy of another. Perhaps I’m being overly generous there?

In any case, this is how I’ve chosen to provisionally represent a relation which the Museum Victoria API expresses only with extreme generality: items which are linked to other items via a JSON array called relatedItems. What is the nature of that relatedness? I don’t actually know, but to find out I will either have to wait for MV to better document the semantics of their JSON, or by spending more time on actual empirical investigation of how that relation is used in their dataset. My initial hypothesis was that “relatedItems” would share some feature in common, and in fact I know this is true in some cases. However it’s also quite possible that the relatedness between two items may not be due to an essential similarity, but rather because they are parts of some larger whole, or have similar provenance, or are contemporaneous, or for any number of other contextual reasons. It may well end up that the relatedItems relation is too general to represent with any of the CRM properties, and I’ll have to resort to some much more general property from another ontology.

That’s a smart convertor but the CRM modeling leaves a lot to be desired.
P3_has_note should be a simple literal, not a node; p70_documents is spelt in lowercase; P130_shows_features_of is for items that are copies of each other not just “generally related”, etc etc etc.

If there’s interest I could review this. I got lots of CRM experience, see https://github.com/usc-isi-i2/saam-lod/wiki/SAAM-LOD-Review and links there. And now mapping Getty CONA.