Allow use of vocabulary to classify relationship between entities

[azaroth42]

There isn't a way in CIDOC-CRM to assert that there is a relationship between two entities, where that relationship is not an existing relation in the ontology. It would be out of scope and inconsistent to create a large number of relations for all the possible relationships between entities, in the same way that we do not create a large number of subclasses for all of the possible classifications of entities.

However there are a large number of not-well-defined, yet still identified, relationships present in many systems. For example ULAN records several hundred relationships between people, and museum collection management systems allow for named relationships between constituents.

In order to fill this need in as simple-as-possible a way that is consistent with the model, I have proposed a Relationship class for the CRMSoc (Society) extension. There isn't a definition or approval for this yet, and in the mean time we should use a local extension that can be migrated to an official class later.

I thus propose the following pattern:

{
  "id": "https://example.museum/data/rels/1",
  "type": "Relationship",
  "_label": "peep 1 is student of peep 2",
  "classified_as": {
    "id": "https://example.museum/data/types/student_of",
    "type": "Type",
    "_label": "student of relationship"
  },
  "from": {"id": "https://example.museum/data/peeps/1", "type": "Person"},
  "to": {"id": "https://example.museum/data/peeps/2", "type": "Person"}
}

Where the domain of from and to are la:Relationship, and their range is crm:E1_CRM_Entity, such that relationships can be asserted between any two resources.

This obviates the need for dc:relation as it can be expressed to the same level of non-precision by a Relationship without a classified_as. However it is an improvement, as the classified_as could be added later without disruption.

Features that are out of scope for this work include qualifying the relationship by time, space or any other facet.

(This issue replaces #107)

[ewg118]

Is there a list of instances of relationship types available somewhere?

[aisaac]

The pattern is probably good. I mean, we have no choice. Still, I'm a bit hesitant to create a specificset of Linked Art constructs for this. We could use the predicates of RDF reification (and I'm actually a bit serious here ;-) ) for the time being.

Side question: why proposing it in CRMSoc? It looks rather like a fundamental modeling pattern than like a social feature.

[aisaac]

Note that there is another alternative: use the URI of the type (from the vocabulary, e.g. your https://example.museum/data/types/student_of) that one wants to use as a property, straight as the predicate of the statement. This pattern as been envisioned when modeling the MARC Relators vocabulary (http://id.loc.gov/vocabulary/relators.html). This is actually feasible in RDF. It's a bit gory though for various reasons. Especially, I'm not sure how it would play out in the JSON-LD-focused approach of Linked Art. But I must mention it for the sake of completeness...

[ewg118]

I disagree that relationship types should be used as a predicate, because 1) it leads to scalability problems within an ontology (need to add more properties for every conceivable relationship) and 2) it makes it difficult to add additional qualifiers about the nature of the relationship, such as place and time period. If you have a generalizable model that @azaroth42 proposes above, that means that many different projects can apply the same model with different sets of relationships. Linked Art can develop relationships relevant for art, SNAC can develop relationship instances relevant for archives (there may be some overlap), and various prosopographical projects are granted the flexibility to define their own relationship types--all while applying the same data model.

[aisaac]

@ewg118 I disagree with the argument about adding more properties. The point of using the concept as a propperty is precisely that the pattern allows to not introduce new properties, as we re-use the types (URIs) as properties directly. This is as friendly to extension as re-using any types that Linked Art or SNAC could introduce, precisely as it's re-using these types. The pattern has drawbacks, but they are not these ones.

About the argument on representing additional qualifiers, I agree with you. But then this is a comment that have a broader scope than this ticket, which has not been raised out of the requirement of adding statement qualifiers. In fact one could say that the issue that you raise applies to the "standard" statements within Linked Art, such as creator etc. If we want qualification for these we'd have to change their patterns too.

[ewg118]

I don't think concepts should be used as properties in an RDF model. Properties and Classes should come from an ontology. When Nomisma.org began (without input from any computer scientists or semantic web experts), some URIs were used as properties and classes simultaneously. They were also instances of concepts in Nomisma itself. It was a mess. I'm not saying it can't be done, because technically you could use SKOS concept URIs as a predicate in a triple and a SPARQL endpoint won't error. But I feel it would actually damage our credibility among semantic web experts to commit what I see as a major faux pas in linked data modeling.

[aisaac]

@ewg118 I agree and thanks for sharing your experience! Note that many people use the word "ontology" to refer to sets of concepts. But indeed I believe we shouldn't encourage this too much...

[workergnome]

Agree with the need for the pattern. This probably means that we need to mint a new micro-vocabulary for the relationship types in ULAN, but that seems doable.

[azaroth42]

Side answer: Because CRMSoc needs it for social relationships, and its easier than getting it into CRMbase. Not a great answer, but it's at least maintained somewhere.

Reification would imply that the type really was a property. It could be just a type from some vocabulary. The MARC relators set is a good example - they were (originally) not defined as properties, just as entries in a vocabulary. Making them into properties by fiat seems both counter to the CRM pattern (assert a Type) and potentially complicating if the maintainers of the vocabulary disagree.

[illip]

We are currently working on a model to describe Canadian Makers and we are using CIDOC CRM PC14 (Carried out by) pattern to identify the role of a person in a relationship. To be honest, we didn't implement anything yet. I understand that your goal is to implement a relationship between any kind of entity but I was wondering if your pattern is aligned with the PC one (http://www.cidoc-crm.org/sites/default/files/CRMpc_v1.0.rdfs). I'm not sure about the status of this implementation though. Also, as CRMsoc is still new, I didn't have the time to read the documentation.

From my understanding, if I used your example with PC14 pattern, it would result in something like:

Peep 1 as Student (PC14) -> p02 has range -> Peep 1 (e21) Peep 1 as Student (PC14) -> p14.1 in the role of -> Student (e55) Peep 2 as Teacher (PC14) -> p02 has range -> Peep 2 (e21) Peep 2 as Teacher (PC14) -> p14.1 in the role of -> Teacher (e55) Peep 1 as Student (PC14) -> p01 has domain -> Teaching activity between Peep 1 and Peep 2 (e7) Peep 2 as Teacher (PC14) -> p01 has domain -> Teaching activity between Peep 1 and Peep 2 (e7) Teaching activity between Peep 1 and Peep 2 (e7) -> p2 has type -> Teaching activity (e55)

The two approaches are slightly different and I'm not sure to know all the pros and cons of each one.

[azaroth42]

It's a good point - CRMPC does play a role in this space - thank you @illip.

I don't believe that PC is the right implementation choice however as it means defining a new class for every relationship (e.g. PC14_carried_out_by). Instead, we could just define a relationship!

The intent is to have a single class that refers (via p2_has_type) to some external vocabulary, which may or may not be a real property. It could just be the concept of teaching, for the student case. PC is a heavyweight approach to solving the issue known in CRM as "properties of properties" (please let's not start that discussion again!), rather than a lightweight approach to introducing new not-entirely-semantic relationships between entities.

[azaroth42]

Agreement on the call of 2019-08-14 for only Actor to Actor (e.g. Person and Group). Social relations are recognizable by society and we want to talk about them.

To be reassessed when we have non-Actor based use cases from data, in particular thoughts as to other areas of potential interest:

• Places (e.g. from TGN)
• Actor to Exhibition (role)
• Actor/Object to Object (specific provenance / roles)

Clarification that "related" without semantics is just a Relationship instance without a classified_as.

[azaroth42]

From the F2F notes, there was an example of "the pet dog of the artist" being depicted in a painting. This would be another instance of a Relationship where one party was not an Actor.

[Habennin]

Question on this issue

I would still argue for representing the 'relation' relation as a relation/property and not a class and give it a .1 property as it would be consistent with the previous modeling choices of CIDOC CRM.

That would look like:

E21 Person pxx has relation E21 .pxx1 had relation type

and restrict this to interpersonal relations to start.

If, however, the choices is to model the 'relation' by a class that stands for the relation, then what would be the names of the relations/properties look like?

Would it be like this:

E21 pxx related by (?) Exx Relation pxx related to E21 Exx Relation p2 has type E55 (insert appropriate interpersonal vocabulary list here)

?

George

[robcast]

@Habennin IANAO (I am not an ontologist) but my problem with having a property on a property like CRM does with P3 and P3.1 is that it is not possible to represent it in simple RDF triples.

Given :a crm:P3_has_note :b how do you formulate a triple with the two parts crm:P3.1_has_type :my_note?

If you (mis-)use the property as a subject crm:P3_has_note crm:P3.1_has_type :my_note you imply that all notes are of type my_note.

For typed notes I go the route of reifying the property into the class PC3 and using P01i and P02:

:a crm:P01i_is_domain_of :a_note
:a_note a crm:PC3_has_note
:a_note crm:P3.1_has_type :my_type
:a_note crm:P02_has_range :b

which is the pattern (like your second exmple) that I think is proposed here. Substitute PC3 with Exx_Relation and P3.1 with P2 and I hope that we can also have nicer properties than P01i and P02 in this case :-)

[azaroth42]

I agree with @robcast's initial point. As with other patterns that could be solved with a .1 property, the result is reification of the relationship into a class in RDF. As we have no option but to use a class, having a specific class with documentation around it is easier to understand than a reification that exposes the ontology rather than the data being modeled. In other words, it's easier to explain and understand a Relationship as a real entity of interest than to explain and understand the reason for reification of a property on a property.

[robcast]

I just implemented @illip 's pattern using 7 triples for one student_of relation because I needed a solution now :-/

Please publish a better solution soon :-)

[illip]

My concerns might be different from yours but I'm wondering how you will manage all the different types of relationships and the expression of their inverse.

Would :studentOfRelationship be enough or you need something more complex like :studentToTeacherRelationship? It depends if you need to manage, for instance, :studentToTutorRelationship. The second option seems more accurate but it would need a bunch of different types. The first one is simpler but what will be the query for someone who's looking for the teacher of X Person?

No matter what choice you make, I think you will need a pattern to manage the inverse and I'm not sure that the inverse of :studentOfRelationship is necessarly :teacherOfRelationship.

That's why I prefer the PC14 pattern for the moment! :)

[robcast]

My preferred solution would be along the lines @azaroth42 suggested (as I understand it):

:a soc:binds :rel
:rel soc:to :b
:rel a soc:Relationship
:rel crm:P2_has_type 'student_of'

Since :binds and :to (from CRMsoc 0.1 draft) represent a directed relation (like P01 and P02 from CRMPC) I see no need to invent an explicit inverse to student_of or to :Relationship but maybe I am missing something.

[aisaac]

It sounds like we're erring more and more towards the pattern of n-ary relationship (or the special case of qualified relations). But looking at the fact that this qualified/n-ary relationship would use very basic and technical constructs ("from", "to", "relation type") wouldn't we be better off re-using directly the primitives of RDF reification with type possibily being the only thing we re-use from CRM?

[robcast]

I like the cited paper about n-ary relations. It also cautions against using RDF reification elements for encoding meaningful relations.

I just found that the SARI project also started an "in social relation" class for this purpose: https://docs.swissartresearch.net/schema/ (using P01 and P02 for domain and range)

[aisaac]

@robcast this is well spotted but in fact I believe my point still holds. Some of the relations in the patterns ("from", "to" in the original example) are not so meaningful. They really indicate that the intention is to represent a statement with the "pseudo-predicate" https://example.museum/data/types/student_of and thus it doesn't seem too wrong to use a vocabulary "designed to talk about statements" (as the n-ary relations paper says) for these two. What is more crucial/specific for us is the relation between the reified statement and the "pseudo-predicate" and for this, indeed, using our own carefully chosen property (CRM type or something else for "classified_as") would seem appropriate.

[aisaac]

I realize that the new DCAT version has tried to solve a similar problem. They do it via a "qualified relation" pattern that's not quite the one I cited above: https://w3c.github.io/dxwg/dcat/#qualified-relationship

It's worth having a look, because this is to be in a W3C spec, albeit in a non-normative part. Also, it does not seek to reproduce RDF reification predicates. I.e. it's not a binary case of the n-ary relationship pattern, it's a bit simpler (though arguably it's not super-simple either - but that's just the fate of any attempt to tackle the problem, I'm afraid!).

[ncarboni]

In order to not have a list of relationships for each case, we defined a new class "in social relationship".

Documentation is available here. We also developed a vocabulary of relationship types (available here ) to go with in.

[azaroth42]

Suggested replacement:

<Teacher> assigned_to_by AttribAssignment .
AttribAssignment assigns <student> ;
     P177 assigned_property_type <teacher-of>

Question - where to find appropriate vocabulary for relationships, as could be very random! Concern - Would want rules for which relationships can be used with which domain/range classes? Search would become terribly complicated / unreliable without consistent guidelines to be followed. How can the relationship be reused?

Concern - Attribute assignment is used for properties frequently which are different from relationships. Also, it should be used for assertions rather than self-evident facts ... some things are purely factual that we would want to provide (e.g. sibling-of)

Concern - CRMSoc will provide social relationships (sub-class of bonds) ; we could work on that to avoid having two different patterns.

Proposal:

Try Attribute Assignment (as above) as it at least improves from the current Relationship extension ; Work with Soc to explore the use of bonds, to determine if it's possible to use before 1.0. If it comes after 1.0, then we can mark this section as "at risk" for change, with a pointer to the soc discussion.

[azaroth42]

• Soc hasn't moved forward at all, so those concerns seem to not be too dangerous.
• Attribute Assignment has become our reification / extension pattern. So while it's not a Relationship, it's not terrible either.
• Vocabulary for social relationships seems out of scope for now, but could be worked on.
• Phases have been generally frowned upon, but would otherwise have been reasonable for this (as relationships are not time-independent)

Will add a reference to the actor page, and a note in the page on assignments.

[azaroth42]

Closed by #588