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
Sexist language in linked.art context #145
Comments
workergnome marks this issue as being discussed in slack |
👍 that this is a gender-biased term, coming from the SIG and the CRM directly. If there's no traction, we could adopt one of the patterns in the above email at the context level. Thanks for raising this! |
So 4 weeks have passed and total radio silence from the SIG. Pro:
Con:
I propose to tag this as defer, and discuss the right way to go in a broader community forum. There is hope for funding to enable participation in a linked.art 1.0 set of workshops, where this would be a great topic. |
The SIG is still silent on this issue, unsurprisingly, however there was an enormous amount of support for the (terrible, IMO) idea to move to just Exxx and Pxxx for the class / property names in RDF. This would give us free reign to rename them in the JSON-LD context to something sensible ... and unrelated to the label in the CRM spec. |
again - I am curious why there is such an emphasis on using 'man-made object' anyway. why use the crm at all for this and just create an expression in an ontology called perhaps: human-made_object. When you start putting linked data triples into documents on the web, the linked data can follow any path. This is not to say that I disagree with following an agreed upon model of some sort for describing art; but if the 'man-made_object' is not a good fit, then it could be defined independently of crm without harm. |
There's not much reaction, but the one that happened was quite interesting (http://lists.ics.forth.gr/pipermail/crm-sig/2018-April/003324.html): this is also a matter of sexism within one language. So we could switch to a language where these issues don't happen ;-) (and I guess this is probably not French) |
Proposal A: Delete Man- from the class names, resulting in Proposal B: Replace Man- with Human- in the class names, resulting in Process -- make both proposals to the SIG, and try to resolve by email. If there's a veto or no consensus, then try to make progress on it at the June meeting. If at June there is no consensus, then use the context to map the class names to more appropriate labels. |
Hi - yes, I am afraid in my enthusiasm - my original post was meant to imply that the replacement term would be in a small ontology that mapped directly as a 'sameAs' to the terms in question --I was not implying that the CRM should not be used. I do have questions about the value of using this term, in general, but I will save those until later as I continue to familiarize myself more with the general way the group is thinking. |
Personally, my preference would be for words like "Artificial" and "Artifact", rather than resorting to phrases like "Human Made Object", which are relatively cumbersome. But I'd support any of the proposed solutions! |
I think I figured out how to phrase my question better @azaroth42 --- When I describe an entity as a tuning fork using the AAT in my system and by- using the inherent inference included in http://vocab.getty.edu/ontology#broaderPreferred, I can query 'sound device' in my system and locate an image of tuning forks that I have not explicitly defined as a sound device. [and as an aside, if I use the wikidata entity for a 'tuning fork' - I can query 'resonator' and find the same image of a tuning fork]. Both of these examples show the usefulness of inference using linked data. But my question related to the CRM use of the term: 'man made object' is why - as part of the getty vocabulary would the AAT not just have a parent of all things that might be ManMade (or HumanMade or Made) in the AAT such that when I define an image of a tuning fork (or anything else human made), the ontology would already know that it is ManMade and thus every object described in the linked art model could skip this part of the definition simply by defining the object as something that the AAT ontology already knows is humanmade. It just seems redundant when you can have an ontology know that something is made by a human that the model would require every component to explicitly be defined this way. In this way, if you said something was a: cabinet perhaps - the ontology not only knows it's furniture, but would know that furniture is human made. I know this is basically off topic from the discussion of appealing to the CRM to change their label, and I also know that I am jumping in here without knowing the previous history of some of the discussions on the use of the 'man made object' term in the model to begin with and I am not sure how far back in the process your discussions began on this topic. Note - I am not arguing for not using the CRM at all for other parts of the model, and obviously I do not know the political process behind terms in the AAT vocabulary - so I hope this question make sense from an outsider perspective. |
AAT is not a CIDOC-CRM based vocabulary. It's just a set of concepts that could be applied to many other ontologies. Also, it doesn't fit into the class hierarchy very well - there are object related concepts in non-object facets, and so on. It could be aligned, but that would be a huge effort for little gain, given that we can draw on the concepts we need, when we need them, regardless of where they sit in the hierarchy. Also, ontologically, making an inference that something is tagged as being related to a concept has a particular class would be quite dangerous. If I tag an object as blue, that doesn't make the object a color. If I tag a string as being materials, that doesn't make it a material, just a string that is a material statement. And the vocabulary content is managed by the Vocabulary program, which Getty Digital supports, but does not set direction for. We could (and will) provide a CIDOC-CRM compatible view of the vocabularies, but only in as much as there will be a E55_Type hierarchy with narrower/broader and the terms as Names (etc.) |
Here my proposal, and ensuing very active thread: http://lists.ics.forth.gr/pipermail/crm-sig/2019-April/003782.html |
@azaroth42 - ok - thank you for the explanation for your choices. If there is another more appropriate thread somewhere for further questions, I can seek it out later. We have cycled through a few experiments in our system and continue to evolve it while we work with real use cases. For a while we were working with blank nodes which relieves your concerns in the second paragraph about tagging class concepts. Our goal has always been to build an intuitive input system for expressing linked data, so while blank nodes are great in theory, they are more difficult in practice in the outside world. Now we are back to working with a skolemization process for differentiating instances of classes from individuals. In either case, it is my intent to continue to evolve our system to accommodate the linked art model as it evolves. I am currently building (among other rdf expressions) triples that use the E22 object/P65 (shows_visual_term)/AAT format. |
"Made" is perfectly understandable and doesn't diverge much from the original term, although if it's going to be changed, would "Produced Thing|Feature|Object" provide for more consistency with other CRM concepts? |
44th CRM SIG meeting approved the unanimous vote to replace "Man" with "Human" in the class labels for:
Which we now need to update in the context document and implementations. |
Preview: https://human_made--linked-art.netlify.com/model/object/identity/ |
Done! :) Closed by #240 :) |
The linkedart.json context file includes the term
ManMadeObject
, which is just a simplification of the official CRM class nameE22 Man-Made Object
.The sexist language is egregious but excusable coming from the CIDOC working group, for many of whom English is a second language, but it could be replaced in the JSON-LD context with inclusive language. e.g.
The text was updated successfully, but these errors were encountered: