Issue #15 - Does groups need a pattern for their list of members?

[chin-rcip]

In the v1.5 of the Target Model, Groups, like Persons, have a pattern for their group belonging, meaning that a group may be part of another groups. In other words, the model only has a "is member of" pattern and not a "has members" one. Therefore, the only way to have a list of actors within a group is to have a group belonging pattern for each actor within this group. Some museums recording groups may have a field for the members of that groups, without necessarily those members documented elsewhere. Therefore, in order to be able to document those members, I see two possibilities: Have a script that, for each member within this list, creates a record and a group belonging member to that group, and therefore keeping the model how it is in v1.5. Add a "has member" pattern, where a group can have a way of documenting its member without necessarily creating new records for those actors. We should be careful that, with this solution, there is no duplicates created, if the membership is documented in the actor record as "is member of" and again in the group record as "has member".

[KarineLeonardBrouillet]

To me, the script option seems to be the cleanest as well as the simplest but I might be missing something? What would be the benefits of using the "has member" option instead?

[Habennin]

I think the cleanest is to extract the members and create individual nodes

[stephenhart8]

I think we all agree. If nobody wants to add something, I'll close the issue.

[Habennin]

+1

[illip]

In your second option (the rejected one), I don't understand why you wouldn't have to create new records? At least you will need to create a URI for the actor, no? If you were thinking of using something like chin:hasMember -> "Jean-Paul Riopelle", it's an absolute "no" for me. :p

That said, when possible, we should avoid creating new classes.

So, +1 for the first option

[Flutifioc]

I don't understand the problem. If we want to find the list of members of a group, we just have to switch the subject and object in the sparql query, something like :

SELECT ?member WHERE { ?member is_member_of chin:group1 }

[stephenhart8]

We are not using the property is_member_of, but the joining and leaving events. Therefore, the question was, when we encounter a dataset documenting a group and simply recording its member list, should we have another pattern, with something similaire to has_member or do we create joining and leaving events for each members. In my opinion it is better to create joining and leaving events.

[Flutifioc]

I see. In that case I agree with the drawn conclusion.

[stephenhart8]

By vote, CHIN has decided, in accordance with everyone, to use scripts to generate the events joining and leaving instead of having a membership list.

[VladimirAlexiev]

@stephenhart8 but could you explain why CHIN rejected the use of current_or_former_member_of and its inverse?

[VladimirAlexiev]

@stephenhart8 @illip I still don't understand why you rejected P107 has current or former member. It's a shortcut of the long path P144i gained member by, E85 Joining, P143 joined, which has these benefits:

• easier to query
• don't need to create a Joining node unless and until you have extra info about the Joining (i.e. date joined)

If you use this PCA and appropriate reasoning:

P107_has_current_or_former_member owl:propertyChainAxiom 
  (P144i_gained_member_by P143_joined).

then P107_has_current_or_former_member will be inferred automatically from the long path, or be stated explicitly for the simple case of no Joining info. It's a win-win for querying.

(Note: it's incorrect to create Leaving unless you have clear evidence the group disbanded or the person left)