-
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
Modeling Gender #13
Comments
The CRM SIG recommends making your own classes, aligned to CIDOC CRM, when CRM does not have the expressive capacity you require. Nevertheless if you wanted to use the 'declaration event' idea without creating a new class then you could simply use E13 Attribute Assignment where the individual doing the attributing and the thing being attributed are the same. ie: E13 -> p2 -> E55 "Gender Declaration" The phase class is still heavily debated even in Linked.art. |
The LGBTQ+ Linked Data Vocabulary Homosaurus - http://homosaurus.org/ - I think can help point to a solution, both in terms of an authoritative vocabulary source and in terms of borrowing from their structure. For example, when it comes to gender, Homosaurus recognizes distinct terms of "assigned gender" and "gender identity" (as well as "culturally specific gender identities"). Assigned-at-birth terms (ie. AFAB/AMAB) could be seen as the activity of the assignation and resulting identity (ie. "Gender Assignment at Birth") with something like @Habennin's "Gender Declaration" activity used to make space for the assertion of non-cis identities and changing identities. P127 could link the broader notion of E55 "Gender Identity" with "Assigned Gender" and "Declared Gender". |
That's a very useful resource, thanks! Also the idea of the 'assigned at birth gender' formulation makes sense. Then you make it clear that this is not what the person says of themselves, but only what an administrative system does? Is that a correct reiteration of what you suggest? So we could actually just one pattern but you would either say the person themselves does the attributing or so institutional source. This would make good sense to me. |
Thank you for this, it is indeed very useful!
|
can you share the draw.io base diagram and I'll present my alternative. More or less we are on the same page. |
Let me know if you have access problems |
I think your Swiss and Canadian examples are both Groups, it doesn't matter one was acquired by birth and another through residence. Using Group allows you to say an artwork was made by unknown Swiss or unknown Canadian; E55 Type is inferior for this. (Come think of it, why should we exclude "nation by conviction"? If I really want to be Qatari -of the rich kind- who should judge me I can't call myself that?) |
@VladimirAlexiev Groups are indeed used for nationality. But as the Cultural Affiliation is more of a loose attribution, we decided to use another pattern. @Habennin What are your alternatives to the modelization of the gender? I think the Phase would be a great option for it. Will documentation on it be released soon? We've decided to separate this issue in two:
|
In preparation for the 11th meeting of the Semantics Committee (June 10). Here is a recording to the presentation made about Homosaurus Vocabulary during the 2020 LD4 Conference : https://ld42020.sched.com/event/cjKm/workshopping-queeries-linked-data-vocabularies-and-ethical-cataloging. We did not document gender for several years, but this issue comes up often when we want to analyze our data. For example, we can't provide data about the presence of women artists in our collections... Having said that, the fact is that our terms are limited to "homme" and "femme" (gender identity) and that this attribution has often been made by the person who catalogs and on the basis of the first name. For now, option 2 pattern would be sufficient. But I think a more inclusive pattern is needed (like option 3), but I don't understand the use of P141 in this example. |
Hi all, at LINCS we are trying out a pattern similar to the E13 one proposed above for representing information about various identities, including gender. The idea behind this comes out of the CWRC/Orlando ontology, specifically about "Cultural Forms". This pattern we are doing is a translation of that to CRM structure, with some additional changes. The idea behind this is to highlight how a lot of the terms that we use to describe various forms of identity are loose in definition, and the same term can be used by different people to mean different things. So instead of connecting directly to a concept, you connect to a text label that represents these things. I'll pop in an overview and example diagram (with annotations), but this is the basic idea: This, like everything else, requires a relationship between structure and vocabularies, and we're working to provide the CWRC vocabularies referenced here as accessible for the shared use. I also highly encourage looking to Homosaurus and other trans metadata projects for vocabularies, especially for the actual label being used (where below in the diagram we have cwrc:woman). I hope this way of thinking is interesting for you and this discussion! Diagram 2: Example - Lousia May Alcott - Gender Edit: FYI, the last bit at the bottom is for how the Orlando Project uses annotations (through the Web Annotation Data Model) to connect to source statements, probably less relevant than the rest for this ticket discussion. |
@eecanning thank you very much for this sharing, I really believe that the proposal that @stephenhart8 and I wanted to make is very close to your proposal. In particular, we were trying to define this famous
These are my first questions, but I will continue to think about the matter in the coming weeks, thank you again, and look forward to discussing it face to face soon! |
@illip that's great to hear! I'm exciting that your and @stephenhart8's thinking has been along similar lines. Some quick responses to some excellent questions:
I do think that part of this is all is that we are using this to discuss association with a wide variety of identity labels, not just gendered ones, and that there are likely nuances for each of those different contexts - there certainly are for gender! |
Having said that, for formal groups, I believe there is a real benefit to documenting this information in order to be able to distinguish between identity and social involvement. Obviously, like all identity fields, the presence of Anyway, look forward to continuing the discussion in a few weeks, thank you very much @eecanning for your contribution. :) |
Following the discussions with @eecanning during the Semantic Committee held on 2021/07/15, it has been decided to continue the discussion on this issue. Here are the conclusions (please comment if things have been wrongly interpreted): The extension CRMsoc, while developing patterns to handle attribution, is still in its early stage of development, and will not be accepted and published for a long time. It has therefore been decided to develop a gender pattern with the tools available without CRMsoc in mind. It appeared that CHIN’s option n°3, involving an instance of Option 1 and 2 are too limited and not expressive enough. Option 4, involving an instance of Even though CHIN’s option 3 and LINCS pattern looks structurally similar, there are some important differences semantically:
The main goal of LINCS’ pattern, in addition to the flexibility that both CHIN and LINCS are looking for, is to avoid imposing modern concepts to people of a different time or culture, as well as not presupposing genders, but rather document the association of individuals and genders. It has been noted during the meeting that the goal of cultural documentation is to record what is publicly stated about someone, and not what could be the private reality of that individual. The goal is therefore to document what has been said about individuals, either false associations or misconceptions. It is then even more important to document the context in which those statements are made. The next goal for this discussion is to find common grounds within the differences between the two approaches, but also decide to what extent the two approaches (LINCS’ and CHIN’s) should be similar. |
Thank you for inviting me to join for this conversation, and for summarizing here so clearly! Edit: As follow-up to this comment - this article was published today about identity and taxonomy, and contains a passage that I think speaks directly to this (the author applies the same concept to "nonbinary" later on):
|
I put this topic into discussion because I think we found a temporary solution, but we still need to think more about this issue and how to model such complex and sensitive matter.
If we agree that Nationality, Nationhood and Communities are groups that you belong to, with a joining and leaving event (either by birth or by citizenship process), things are different for cultural affiliation and gender.
Cultural affiliation, understood as cultural milieu we live in and that we keep all our life, does not have a joining and leaving event. A Swiss person, born and raised his first years of his life in Switzerland and then moved out to Canada during his teenage years, would have the Swiss culture, but would also imbued the Canadian culture if he stays in Canada for some years.
Therefore, the modeling of the Culture with the Group Belonging pattern is not correct, and maybe the
P2_has_type ->E55_Type
would be more accurate.Gender belonging is on the contrary much more complex than the
P2_has_type->E55_Type
pattern. Nonetheless, the Group Belonging is not appropriate as gender can not be modeled as aE74 Group
.Linked.art and CIDOC CRMSoc are developing a "Phase" concept, that would allow to document those kind of "non-physical statements" about a
E21 Person
. It is better to wait and see how this is developed.Another solution, proposed by George Bruseker, would be to create a "declaration event", that would model the gender as a declaration statement, either made by the person or an institution. I am not really in favor of creating our own classes.
The text was updated successfully, but these errors were encountered: