-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue #15 - Does groups need a pattern for their list of members? #15
Comments
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? |
I think the cleanest is to extract the members and create individual nodes |
I think we all agree. |
+1 |
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 That said, when possible, we should avoid creating new classes. So, +1 for the first option |
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 { |
We are not using the property |
I see. In that case I agree with the drawn conclusion. |
By vote, CHIN has decided, in accordance with everyone, to use scripts to generate the events |
@stephenhart8 but could you explain why CHIN rejected the use of |
@stephenhart8 @illip I still don't understand why you rejected
If you use this PCA and appropriate reasoning: P107_has_current_or_former_member owl:propertyChainAxiom
(P144i_gained_member_by P143_joined). then (Note: it's incorrect to create |
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".
The text was updated successfully, but these errors were encountered: