Add implementation warning for multi-class instances

[mdlincoln]

Since it seems to be a major departure that has implications for software architecture? (suggestion by @joshuago78)

[workergnome]

This should probably be a conversation—I'm not convinced that it's a bad idea to have objects have different classes, particularly if we're ever planning on incorporating multiple ontologies to accommodate concepts that don't work well in the CIDOC-CRM.

[azaroth42]

As two data points:

• Cromulent has a special, hard coded class to handle creating activity+eoe for the destruction of objects: https://github.com/gri-is/crom/blob/master/cromulent/extra.py#L21 and similarly hard coded reading of it back in again from JSON:
  https://github.com/gri-is/crom/blob/master/cromulent/reader.py#L61

• Arches doesn't support it, despite also being a CRM implementation for much longer than Cromulent has existed. The issue https://github.com/archesproject/arches/issues/2307 captures the lack. The proposed solution is also a custom class that could be then transformed again on the way out.

While type is just another predicate, it's often treated as special. Consider @type with its hard coded rules in JSON-LD. Also given the interaction with Object Oriented programming systems, and graph <--> object mapping, where an instance can be of one class only.

At the triples/triplestore level, type is just an edge in the graph. But above that, I agree that a warning would be appropriate.

[workergnome]

This is a pretty significant limitation that we're imposing on ourselves. We're disallowing a core feature of RDF (multi-typing) due to a desire to have it match with the limitations of a different domain. And we're not very consistent in it, either: for instance, we're using rdf:value, which means that all of our entities are also instances of rdfs:Resource. Cromulent is also hard-coding in that dependency, I believe, and I think we've convinced Arches to do the same. We're implying the class, but it means that we can't run validation against the other properties that we'd expect.

But as we start incorporating more and more ontologies, the special cases are likely to overwhelm the work that it would take to actually do it the way that RDF suggests.

[azaroth42]

I don't follow the rdf:value issue? If we're including inferencing from domain/range, then everything is multi-classed, those classes are just somewhere up the hierarchy ... like rdfs:Resource is. Even if CRM's ontology definition doesn't explicitly declare that E1 is a subClassOf Resource, the rules of RDF make it so.

We can expand our data points though and look what other libraries do. I've asked what ActiveTriples does, and ruby also has ActiveRDF. I'll investigate what SuRF does.

For the scope of linked.art, I think we can stick pretty close to CIDOC-CRM. The further towards other domains we get, the less fidelity we get ... which is appropriate IMO ... but we don't need to make a super-profile of CRM+BibFrame+RiC+whatever else for interoperability of linked art.

[azaroth42]

ActiveFedora (built on ActiveTriples):

this was a problem for AF & fedora 3 content models, & I had to monkey-patch rdf-xml not to use first one as root element! good times. @Barmintor

And the underlying ActiveTriples:

The simple answer is first. This isn't great, since which type is "first" can vary depending on HAMT rebalances, but there it is. @no_reply

SuRF doesn't allow for multiple classes at the same time either, you have to pick one when you create the resource out of the store. For example, using the example code TimBL can be either a FoafPerson or a ConMale, but he isn't both at once at the code level. The objects store full set of rdf:type assertions.

>>> a[0].rdf_type
[rdflib.term.URIRef(u'http://xmlns.com/foaf/0.1/Person'), rdflib.term.URIRef(u'http://www.w3.org/2000/10/swap/pim/contact#Male')]
>>> type(a[0])
<class 'surf.resource.FoafPerson'>

[Conal-Tuohy]

So, is the intended warning/admonition to be something to the effect of "if you are implementing the Linked Art model on top of a layer provided by object-oriented framework that doesn't support polymorphism, then you will need to handle this case specially?"

Personally, I don't currently have any skin in that game, but I'm interested to see from @azaroth42's comments above about how some RDF/OO binding mechanisms work (or don't work) in practice.

I also thought "why not create a superclass that unites the two classes?" and I see this is what Arches does. Pragmatically, would it be justifiable to include this superclass as part of the Linked Art ontology?

Also, re @workergnome's point about other ontologies, there are also the geospatial types to consider; i.e. depending on what's decided with respect to the geospatial model, there may be polymorphic types straddling the border of CIDOC-CRM and GeoSPARQL or Basic Geo.

[azaroth42]

Yes, the challenge is that it's not multiple inheritance (you need that regardless), it's true polymorphism where the same instance is at the same time an instance of more than one class and should have the functionality/requirements of all.

I also thought "why not create a superclass that unites the two classes?" and I see this is what Arches does. Pragmatically, would it be justifiable to include this superclass as part of the Linked Art ontology?

For the sake of one new class (EoE + Activity), that seems justified to add to our ontology to me. It would make it easier for everyone, rather than ending up with many such classes being defined. Are there other such requirements within CIDOC-CRM? Here I ask about Place+Object as opposed to an object with a permanent location of a Place. We can solve that one with the relationship, rather than the multi-classing.

[Conal-Tuohy]

ask about Place+Object as opposed to an object with a permanent location of a Place. We can solve that one with the relationship, rather than the multi-classing.

I don't follow that. Doesn't the same issue arise with instances of crm:E53_Place which are also instances of geo:Point?

[azaroth42]

Doesn't the same issue arise with instances of crm:E53_Place which are also instances of geo:Point?

Yes, if the same resource were an instance of both classes (rather than E53 some-property geo:Point), it would definitely be the same problem.

[workergnome]

VisualItem and IIIF Manifest is another example.