Skip to content
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

Closed
Conal-Tuohy opened this issue Apr 3, 2018 · 17 comments
Closed

Sexist language in linked.art context #145

Conal-Tuohy opened this issue Apr 3, 2018 · 17 comments
Labels
enhancement The issue describes an improvement to existing functionality or new functionality priority The issue is high priority for coming to a solution

Comments

@Conal-Tuohy
Copy link

The linkedart.json context file includes the termManMadeObject, which is just a simplification of the official CRM class name E22 Man-Made Object.

  "ManMadeObject": "crm:E22_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.

  "Artefact": "crm:E22_Man-Made_Object"
@azaroth42
Copy link
Collaborator

workergnome marks this issue as being discussed in slack

@azaroth42
Copy link
Collaborator

👍 that this is a gender-biased term, coming from the SIG and the CRM directly.
I've raised the issue with them: http://lists.ics.forth.gr/pipermail/crm-sig/2018-April/003323.html

If there's no traction, we could adopt one of the patterns in the above email at the context level.

Thanks for raising this!

@azaroth42 azaroth42 added the enhancement The issue describes an improvement to existing functionality or new functionality label Apr 4, 2018
@azaroth42
Copy link
Collaborator

So 4 weeks have passed and total radio silence from the SIG.

Pro:

  • It's the socially responsible thing to do!

Con:

  • We don't change the names of other classes beyond the algorithm.
  • It obfuscates the classes without technical benefit.

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.

@azaroth42 azaroth42 added the defer Progress and discussion on the issue has been postponed label Apr 30, 2018
@azaroth42
Copy link
Collaborator

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.

@zeroexp
Copy link

zeroexp commented Apr 10, 2019

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.

@aisaac
Copy link
Collaborator

aisaac commented Apr 10, 2019

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)

@azaroth42
Copy link
Collaborator

azaroth42 commented Apr 10, 2019

Proposal A: Delete Man- from the class names, resulting in MadeObject, MadeFeature and MadeThing. (9 in favor)

Proposal B: Replace Man- with Human- in the class names, resulting in HumanMadeObject, HumanMadeFeature and HumanMadeThing. (5 in favor)

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.

@azaroth42 azaroth42 removed the defer Progress and discussion on the issue has been postponed label Apr 10, 2019
@zeroexp
Copy link

zeroexp commented Apr 10, 2019

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.

@Conal-Tuohy
Copy link
Author

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!

@zeroexp
Copy link

zeroexp commented Apr 11, 2019

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.

@azaroth42
Copy link
Collaborator

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.)

@azaroth42
Copy link
Collaborator

Here my proposal, and ensuing very active thread: http://lists.ics.forth.gr/pipermail/crm-sig/2019-April/003782.html

@zeroexp
Copy link

zeroexp commented Apr 12, 2019

@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.

@beaudet
Copy link
Collaborator

beaudet commented Apr 24, 2019

"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?

@azaroth42
Copy link
Collaborator

44th CRM SIG meeting approved the unanimous vote to replace "Man" with "Human" in the class labels for:

  • E22 Human-Made Object
  • E24 Physical Human-Made Thing
  • E25 Human-Made Feature
  • E71 Human-Made Thing

Which we now need to update in the context document and implementations.

@azaroth42
Copy link
Collaborator

Preview: https://human_made--linked-art.netlify.com/model/object/identity/
(and all the rest of the pages)

@azaroth42 azaroth42 added in progress priority The issue is high priority for coming to a solution labels Jun 15, 2019
@azaroth42
Copy link
Collaborator

Done! :) Closed by #240 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement The issue describes an improvement to existing functionality or new functionality priority The issue is high priority for coming to a solution
Projects
None yet
Development

No branches or pull requests

5 participants