how to express creator roles and display order of the data

[beaudet]

This is part of a production activity.

How can I best convey the data for the role and displayOrder listed below? Wrangling the JSON generation code to convey the ordering via the natural ordering within the JSON seems unlikely to cause that ordering to be retained if the data is manipulated in various ways, so I'd prefer to be explicit about it. It's certainly tied to the "view" but I it's also expressive of a desired curatorial ordering so it should be present in more than just the order of the array in which it appears I think. Also, in the context of object creation, the creator is always listed with a roleType of "artist" in our particular data, but there are numerous sub-roles under "artist", e.g. painter, sculpture, etc. and those roles are specific to the intersection of the created object and the creator, not a general professional capacity the artist has.

Is there a way to express either or both of these in the data without having to resort to a custom property container like custom_metadata?

    "carried_out_by": [
        {
            "id": "https://id.nga.gov/1c36bc84-1afa-4a6d-972a-f9b437e94bd4",
            "type": "Actor",
            "_label": "Arbo, Aurelia",
            "custom_metadata": {
                "roleType": "artist",
                "role": "artist",
                "displayOrder": 1
            }
        }
    ],

[beaudet]

In a Slack conversation, Rob suggested that the following (either technique or classified_as) could be used to represent the "role" an artist plays in a production activity.

  "produced_by": {
  "type": "Production",
  "part": [
    {
      "type": "Production",
      "label": "First Stage of Production",
      "technique": [
          {
            "id": "http://vocab.getty.edu/aat/300264383",
            "type": "Type",
            "_label": "Sculpting"
          }
      ],
      "carried_out_by": [
          {
            "type": "Person",
            "_label": "Sculptor"
          }
      ],      
      "attributed_by": [
        {
          "type": "AttributeAssignment",
          "assigned": {
            "id": "https://vocab.getty.edu/aat/300192339",
            "type": "Type",
            "label": "sequences"
          },
          "value": 1
        }
      ]
    }, ...

This seems ok, but it would require me to:

1. map all 50+ roles for artists to terms, likely requiring new terms to be minted (not an insurmountable problem)
2. NOT include the given name of the role in our TMS system except perhaps via the _label on the classification or technique and _label isn't the same thing as data.

Alternatively, I found this: https://cidoc-crm.org/sites/default/files/Roles.pdf

which suggests a mechanism using the property p14.1 to add a property to carried_out_by that allows the nature of an Actor’s participation to be specified directly rather than having to map to technique.

https://www.cidoc-crm.org/Property/P14-carried-out-by/Version-6.2.1

How feasible would it be to incorporate this option within the Linked Art standards? I'd like to propose that we adopt that property.

[beaudet]

Rob: There's no way to express the .1 meta-properties in RDF :disappointed:

beaudet wuh? really? how are they used in practice? requires a quad store? what about any of the other solutions proposed here? https://cidoc-crm.org/sites/default/files/Roles.pdf

What about this?

{
  "@context": "https://linked.art/ns/v1/linked-art.json",
  "id": "http://example.org/object/123",
  "type": "HumanMadeObject",
  "_label": "An Intricate Sculpture",
  "produced_by": {
    "id": "http://example.org/production/event/456",
    "type": "Production",
    "_label": "Creation of An Intricate Sculpture",
    "carried_out_by": [
      {
        "type": "Actor",
        "_label": "Sculptor",
        "classified_as": [
          {
            "id": "http://vocab.getty.edu/aat/300025103", // AAT for 'sculptors'
            "type": "Type",
            "_label": "Sculptor"
          }
        ]
      },
      {
        "type": "Actor",
        "_label": "Metalworker",
        "classified_as": [
          {
            "id": "http://vocab.getty.edu/aat/300025104", // AAT for 'metalworkers'
            "type": "Type",
            "_label": "Metalworker"
          }
        ]
      }
    ],
    "part": [
      {
        "id": "http://example.org/production/part/112",
        "type": "Production",
        "_label": "Molding Process",
        "carried_out_by": [
          {
            "id": "http://example.org/person/789",
            "type": "Person",
            "_label": "Alex Johnson, Sculptor"
          }
        ]
      },
      {
        "id": "http://example.org/production/part/113",
        "type": "Production",
        "_label": "Finishing Process",
        "carried_out_by": [
          {
            "id": "http://example.org/person/1011",
            "type": "Person",
            "_label": "Chris Smith, Metalworker"
          }
        ]
      }
    ]
  }
}

This way, the overall carried_out_by conveys the roles and the specific parts of the production convey the actual people. Maybe hacky, but hopefully valid and conveys the role rather than technique or process.

This would require alignment between the two arrays to make it work, so in that sense, it relies on the array ordering present in the data which I'm not a huge fan of but it seems like a better option than having to jettison "role" entirely or having to create custom metadata to represent it.

This option seems slightly more "correct" than using two Actors for the carried out by where the bnode for the actor indicates the role. OR... maybe we use an equivalent here? Is that even an option with a bnode?

carried_out_by ->
   type: person
   _label: "role of actor"
   classified_as : Sculptor
   equivalent: -> http://example.org/person/1011, "Person", "Chris Smith, Metalworker"

as opposed to:

carried_out_by ->
  [ http://example.org/person/1011, "Person", "Chris Smith, Metalworker" (edited)
   , "Person", "role of actor"
          classified_as : Sculptor
   ]

which would have a bnode classifying the role, perhaps with an equivalent itself pointing back to the first entry?

[beaudet]

or we could just use an attribute assignment until we have time to discuss the options a little more. What do you think about this:

        {
            "type": "Production",
            "_label": "production of 1937.1.74: A Girl with a Broom",
            "timespan": {
                "type": "Timespan",
                "begin_of_the_begin": "1646-01-01T00:00:00Z",
                "end_of_the_end": "1651-12-31T11:59:59Z"
            },
            "part": [
                {
                    "type": "Production",
                    "_label": "a subset of the overall production",
                    "carried_out_by": [
                        {
                            "id": "https://id.nga.gov/439f5edd-efcc-457d-89a8-f41e652dd854",
                            "type": "Actor",
                            "_label": "Dutch 17th Century"
                        }
                    ],
                    "assigned_by": [
                        {
                            "type": "AttributeAssignment",
                            "assigned": [
                                {
                                    "id": "https://vocab.getty.edu/aat/300192339",
                                    "type": "Type",
                                    "_label": "sequences"
                                }
                            ],
                            "value": "1"
                        },
                        {
                            "type": "AttributeAssignment",
                            "assigned": [
                                {
                                    "id": "https://vocab.getty.edu/aat/300435108",
                                    "type": "Type",
                                    "_label": "roles"
                                }
                            ],
                            "value": "painter"
                        }
                    ]
                },
                {
                    "type": "Production",
                    "_label": "a subset of the overall production",
                    "carried_out_by": [
                        {
                            "id": "https://id.nga.gov/b4013193-bfeb-413c-a1f7-d67aab87c15a",
                            "type": "Actor",
                            "_label": "Rembrandt van Rijn"
                        }
                    ],
                    "assigned_by": [
                        {
                            "type": "AttributeAssignment",
                            "assigned": [
                                {
                                    "id": "https://vocab.getty.edu/aat/300192339",
                                    "type": "Type",
                                    "_label": "sequences"
                                }
                            ],
                            "value": "2"
                        },
                        {
                            "type": "AttributeAssignment",
                            "assigned": [
                                {
                                    "id": "https://vocab.getty.edu/aat/300435108",
                                    "type": "Type",
                                    "_label": "roles"
                                }
                            ],
                            "value": "related artist"
                        }
                    ]
                },
                {
                    "type": "Production",
                    "_label": "a subset of the overall production",
                    "carried_out_by": [
                        {
                            "id": "https://id.nga.gov/af35bd56-8b16-476e-8da0-e5a80d966144",
                            "type": "Actor",
                            "_label": "Fabritius, Carel"
                        }
                    ],
                    "assigned_by": [
                        {
                            "type": "AttributeAssignment",
                            "assigned": [
                                {
                                    "id": "https://vocab.getty.edu/aat/300192339",
                                    "type": "Type",
                                    "_label": "sequences"
                                }
                            ],
                            "value": "3"
                        },
                        {
                            "type": "AttributeAssignment",
                            "assigned": [
                                {
                                    "id": "https://vocab.getty.edu/aat/300435108",
                                    "type": "Type",
                                    "_label": "roles"
                                }
                            ],
                            "value": "painter"
                        }
                    ]
                }
            ]
        }
    ]

[cbutcosk]

@beaudet FWIW we use the pattern Rob outlined in slack (+/-) on o'keeffe and duchamp and it's been fine across ~20-50 technique terms.

If your role terms are backed by TMS is there a reason you're concerned about emitting custom URI terms? As a producer and user of this kind of data I usually consider local contextual URIs like the kind you're considering emitting much more useful than their vocabulary term (ditto for the whole term hierarchy in one's CxMS, but I digress).

Just saying--were we to do those datasets over again we'd probably be more liberal with custom URI terms and let the chips fall wherever on mapping to AAT/WD/etc vocabulary URIs because at the end of the day your dataset is possibly an authority for someone else so emitting your actually-used data in a first-class way is very useful for everyone.

[Habennin]

Dear David,

There is a way of expressing .1 properties in RDF. They are officially released as PC classes on the CRM site.

These materialize the property as a class and then express the .1 class as having the domain of the materialized property.

This look like this for 'creator'

E22 -> P108i was produced by -> E12 Production ->P01i is range of ->PC14 carried out by ->P02 has range -> E39 E22 -> P108i was produced by -> E12 Production ->P01i is range of ->PC14 carried out by ->P14.1 in the role of -> E55 Type

What is good about this is that it expects a concept (E55) which is the normal type that people put on 'printer', 'painter' etc.

The bad thing is that it materializes a property and because of some CIDOC CRM arcana the PC classes are not under E1 CRM entity so you cannot then go on to add the extra properties that you suggest like a series number etc. This can be worked around by editing the RDF of course...

This is not linked.art however which suggests:

E22 -> P108i was produced by -> E12 Production ->P9 is composed of -> E12 Production -> P14 carried out by -> E 39 E22 -> P108i was produced by -> E12 Production ->P9 is composed of -> E12 Production -> P2 has type -> E55

The problem with this is that the type here is on the sub production event but the type typically assigned in normal documentation practice is 'creator' etc. but this is not what you would imagine having here. Rather you would have 'creating', 'printing', 'painting'. All of which anyhow you might put under P32 used technique.

The good thing about this is that E12 is a regular class then you can start putting on identifiers and names etc. all of which could be suitable for your case.

To me it is not obvious why you need to use attribute assignment for all this. You could just use identifier and a type. Value = 1, Type = Artist Order.

There you are only generating one new URI for a type (or maybe one already exists...)

Here is another proposal that I think is worth considering although again it is not linked.art classic.

With SARI we have developed an ontology extending the CIDOC CRM to handle social facts. A social fact is one that has its identity in the group intentionality of a fact, we take x to be the case for y. This was not originally developed with idea of covering the case of authorship but the more I work with groups concerend with authorship / artistship the more applicable I think it is.

My basic contention would be that the usual asssertion of the fact of someone being the creator or artist of an object in a documentation is not in fact accurately expressed by the normal CRM phrase

E22 -> P108i was produced by -> E12 Production ->P14 carried out by -> E39

The above phrase retranslated to normalish English basically says There was an object created by an event in space time in which an individual participated. The emphasis is on the physics of the case. It is making a statement that person X was there in that event with that object that was created. But this is far from clear either in present day art practice or in historical art practice. Has Damien Hirst been in the room with the formaldehyde shark at the moment of its production? Maybe. Maybe not. We probably don't know and we may never be able to know. Also this isn't what people are recording or interested in investgating. It is not that we want to know if Damien Hirst and the formaldehyde shark met in a space time volume. Historical research wants to know who was attributed or asserted or taken to be the case to be the author / artist / creator of the thing. It is a social fact of a collective ascription of a role in relation to the object's creation rather than an assertion about spacetime coordinates.

If you buy the above argument this is the alternative modelling I suggest based on the new ontology (CRM Art and Architectural Argumentation or CRMaaa):

E22 -> P108i was produced by -> E12 Production -> ZP75i is context for -> ZE6 Social Status -> ZP17 has social status subject -> E39

E22 -> P108i was produced by -> E12 Production -> ZP75i is context for -> ZE6 Social Status -> ZP18 ascribes social status -> E55

The first sentence says that there was an object made by an event of production in space time whcih was the context for a person having a social status

The second sentence says that social status was x (painter, printer etc.)

This seems closer to the actual information recorded and argued about.

This has the advantage that all CRMaaa classes are harmnized to CIDOC CRM and thus Social Status isA E2 Temporal Entity and therefore can have identifiers, names and so on as you require. It has the very large advantage as well that it is closer to the actual intention of the original documentation and that it doesn't require a clumsy workaround like PC classes. The major disadvantage in this case would be that it is not canonical linked.art.

You can find the specification for CRMaaa here:

https://github.com/takinsolutions/crmaaa/tree/main

This issue caught my eye and so I thought I would put in this rather long answer. I don't know if it immediately seems attractive as a solution to you but since there are many cases like this that need solving and don't seem totally solved by Linked.Art anymore than regular CRM, I thought I would write this up to put it into the conversation for the future.

Sincerely,

George

Sorry I put my examples in regular crm form but I remember those labels and not the linked.art json labels. Nevertheless I have indicated where it corresponds and where not.

[beaudet]

Thanks all. Sounds like good material for an upcoming call. The discuss label is applied to this issue.

In the interest of meeting a deadline, I've been chatting with Rob on Slack about alternatives that are more linked art compliant as linked art is currently spec'd.

What are your respective thoughts about the following alternative that uses LinguisticObject rather than custom properties like _role and _sequence to convey that data?

I do have a mapping of each artist role to an AAT concept although that's not cross-walked to techniques yet. That's important but not urgent for us and it could be added later once the mapping is done.

    "produced_by": [
        {
            "type": "Production",
            "_label": "production of 1937.1.74: A Girl with a Broom",
            "timespan": {
                "type": "Timespan",
                "begin_of_the_begin": "1646-01-01T00:00:00Z",
                "end_of_the_end": "1651-12-31T11:59:59Z"
            },
            "part": [
                {
                    "type": "Production",
                    "_label": "part of the overall production",
                    "carried_out_by": [
                        {
                            "id": "https://id.nga.gov/439f5edd-efcc-457d-89a8-f41e652dd854",
                            "type": "Actor",
                            "_label": "Dutch 17th Century"
                        }
                    ],
                    "referred_to_by": [
                        {
                            "type": "LinguisticObject",
                            "content": "painter",
                            "classified_as": [
                                {
                                    "id": "https://vocab.getty.edu/aat/300435446",
                                    "type": "Type",
                                    "_label": "creator description"
                                }
                            ]
                        },
                        {
                            "type": "LinguisticObject",
                            "content": "1",
                            "classified_as": [
                                {
                                    "id": "https://vocab.getty.edu/aat/300444118",
                                    "type": "Type",
                                    "_label": "arrangement description (sequence)"
                                }
                            ]
                        }
                    ]
                },
                {
                    "type": "Production",
                    "_label": "part of the overall production",
                    "carried_out_by": [
                        {
                            "id": "https://id.nga.gov/b4013193-bfeb-413c-a1f7-d67aab87c15a",
                            "type": "Actor",
                            "_label": "Rembrandt van Rijn"
                        }
                    ],
                    "referred_to_by": [
                        {
                            "type": "LinguisticObject",
                            "content": "related artist",
                            "classified_as": [
                                {
                                    "id": "https://vocab.getty.edu/aat/300435446",
                                    "type": "Type",
                                    "_label": "creator description"
                                }
                            ]
                        },
                        {
                            "type": "LinguisticObject",
                            "content": "2",
                            "classified_as": [
                                {
                                    "id": "https://vocab.getty.edu/aat/300444118",
                                    "type": "Type",
                                    "_label": "arrangement description (sequence)"
                                }
                            ]
                        }
                    ]
                },
                {
                    "type": "Production",
                    "_label": "part of the overall production",
                    "carried_out_by": [
                        {
                            "id": "https://id.nga.gov/af35bd56-8b16-476e-8da0-e5a80d966144",
                            "type": "Actor",
                            "_label": "Fabritius, Carel"
                        }
                    ],
                    "referred_to_by": [
                        {
                            "type": "LinguisticObject",
                            "content": "painter",
                            "classified_as": [
                                {
                                    "id": "https://vocab.getty.edu/aat/300435446",
                                    "type": "Type",
                                    "_label": "creator description"
                                }
                            ]
                        },
                        {
                            "type": "LinguisticObject",
                            "content": "3",
                            "classified_as": [
                                {
                                    "id": "https://vocab.getty.edu/aat/300444118",
                                    "type": "Type",
                                    "_label": "arrangement description (sequence)"
                                }
                            ]
                        }
                    ]
                }
            ]
        }
    ],

[edwardanderson]

I like the look of these "arrangement description" helpers. We also have a need for representing sequence within Production parts but have so far been reluctant to map out something with Dimension.

[Habennin]

why linguistic objects and not identifiers? It seems the case for putting an identifier

[cbutcosk]

+1 on using Identifier in most cases for sort order

One thing to consider in modeling sort order in this way though -- it may be altogether better to model this as a client concern depending on your dataset scale and the ordering guarantees your backend and/or pipeline is capable of making.

[beaudet]

@Habennin @cbutcosk - curious about your thoughts on why an Identifier is more semantically appropriate for sequence than Linguistic Object and can you please share a JSON-LD example showing what you mean along with an appropriate term for classifying the sequence? There is a "sequences" term in the AAT, but that seems better suited to the overall production activity representing a sequence than an individual sequence value per se.

I am creating a local URI for nearly every application of concepts in the graph, but where there is an opportunity to use an existing standard directly, I'm using it directly.

Is there documented guidance on the creation of custom terms, particularly the definition of "meta-type" and examples of custom concepts showing the use of both meta-types and composite concepts along with an explanation of how to interpret the semantic meaning each when used?

@cbutcosk - Can you please elaborate on what you mean by a client concern, the scale, etc.? There is only one sequence of artists and it's curatorially assigned in TMS. So, being data, shouldn't it be expressed explicitly in the JSON-LD?

[Habennin]

Here's the json:

"identified_by": [ { "type": "Identifier", "classified_as": [ { "id": "https://vocab.getty.edu/aat/300444118", "type": "Type", "_label": "arrangement description (sequence)" } ], "content": "1" }

just modifid from here:

https://linked.art/model/base/

And here would be my thinking:

Why identifier? because both the property and the class are more appropriate. You are assigning a number to the event not describing it with a text. Identifier is for identifiers and linguistic object should be for texts. The integer assigned doesn't refer to the event, it is an identifier for it.

[beaudet]

So it's an identifier of the sequence within the scope of it's parent activity? What about using a concept that clearly states "description" even though it's an integer? The arrangement description concept seems more appropriate for LinguisticObjects.

looking at the hierarchy here: https://www.getty.edu/vow/AATHierarchy?find=sequence&logic=AND&note=&subjectid=300404049

I think using the "positional attributes" concept might be a better choice? Positional attributes by sequence is a guide term so I assume that's not an option, so going up the hierarchy shows "positional attributes" as the first concept choice.

"Note: Attributes relating to position, which include context, orientation, portions of a whole, or relative to other properties."

[azaroth42]

There's several issues here which I think is generating some of the confusion.

Sorting:

• It cannot be a Dimension (as activities and places don't have Dimensions)
• It should be follow the principles and existing patterns if possible
• It should work for a list of blank nodes in a single record, and a list of records.
• As such, I agree that an Identifier with a sortable value is the way to go, classified as some convenient term.
• I agree it's not a LinguisticObject for sorting, as it's not based in a Language. It's almost certainly a non-linguistic string value.

Roles:

• We've had the activity partitioning pattern for a long time now. I don't think we should change it.
• So then there's the question of associating the role with the partition. The easiest case is technique if you have structured data, or if you're wary of technique: painter (e.g. the role of the person, not the technique) then classified_as is at least a bit more "squishy" semantically.
• If you have a string ... a LinguisticObject associated with the part that gives a human readable form. "Architect: Louis Kahn" is a fine description of Kahn's part of the work of producing the YCBA building.

[beaudet]

For sorting, sounds like Identifier - hopefully we can select a recommended or required concept from AAT or other source to use in the Linked Art spec to standardize on how to represent the sequence of a part within a whole explicitly rather than relying on order of the JSON array?

I could also create a custom term for sequence with a metatype of "positional attributes" but given this might be a shared pattern, best to just decide and document?

I am indeed wary of applying roles to techniques but I'm not sure I'm a fan of classifying an activity with a term more applicable to Actors. It sounds like for now at least, the best pragmatic and semantically correct answer is to map the roles to techniques and / or mint custom concepts as necessary and to continuing supplying the needed value for the role as a referenced linguistic object classified as a creator description.

Maybe we can investigate the .1 properties at some point after release 1.0 since that would allow the role used to be directly linked to the sub-activity performed by the artist?

My data on role is as a string but those role labels are sourced from the TMS role types table, so they are controlled. I've created local concepts to represent them all and they also reference AAT terms, but they've not been cross-walked to technique yet. Is there a semantically appropriate way to create a local Concept for technique that binds together both the role and the technique as one?

So, I'd probably want to include the technique and the string as a linguistic object.

[beaudet]

That would presumably look this this:

                {
                    "type": "Production",
                    "_label": "'part of the overall production'",
                    "technique" : [{
                        <include when mapping from roles to techniques is complete>
                    }],
                    "carried_out_by": [
                        {
                            "id": "https://id.nga.gov/439f5edd-efcc-457d-89a8-f41e652dd854",
                            "type": "Actor",
                            "_label": "Dutch 17th Century"
                        }
                    ],
                    "identified_by": [
                        {
                            "type": "Identifier",
                            "content": "1",
                            "classified_as": [
                                {
                                    "id": "https://vocab.getty.edu/aat/300010269",
                                    "type": "Type",
                                    "_label": "positional attributes"
                                }
                            ]
                        }
                    ],
                    "referred_to_by": [
                        {
                            "type": "LinguisticObject",
                            "content": "painter",
                            "classified_as": [
                                {
                                    "id": "https://vocab.getty.edu/aat/300435446",
                                    "type": "Type",
                                    "_label": "creator description"
                                }
                            ]
                        }
                    ]
                },

[Habennin]

@azaroth42 and @beaudet with CRMaaa we have managed to provide a systematic response to some of the main expressive shortfalls of CIDOC CRM for documenting social facts. We enrich CIDOC CRM with a well founded theory for documenting socially grounded collective facts for things like 'appellation status', 'social status', 'right status' and more. The PC classes are a kludge for an undermodelled world of social facts for which there is good theory and now a good ontology. I'd be glad to present about it in relation to a post 1.0 reconsideration of modelling.

[azaroth42]

:) From a quick skim, it looks like a good way to think about States / Phases. But agree this has to come after 1.0.

[azaroth42]

Order: Agreed on using Identifier. For different contexts of sort add an AttributeAssignment to the Identifier (as per same identifier from different organizations). Needs an AAT for classifications. Needs process to request AATs to be added -- perhaps a spreadsheet that could be shared.

Suggestion is "Sort Value" under "Categories of Information" along side "Title/Name" and then "Sort Title" would have a second parent of "Sort Value" as well as "Title/Name".

Use Sort Title for now if necessary, ask AAT for a new one, and see if it will come. If not, then we'll create one under Linked Art.

[azaroth42]

Role: Accepted LO and technique, with classified_as as the hold-your-nose for semantic queasiness [tm] of a role being applied to an activity.

Daniel has a spreadsheet of the connection between technique and role to be shared. Can ask for new AATs if there's one half missing.

[benosteen]

Just to follow up on the original suggestion of using an AttributeAssignment to represent the agent having a role during the activity, if we do have terms for all the descriptors (eg MARC Relator URIs), is this structure still viable or even suggested?

Secondly, there is this section of the model guide https://linked.art/model/assertion/#context-specific-assertions about Context Specific Assertions, which I'd argue that fits with the role an agent had to play in an activity. It's not asserting that they had this assertion outside of it, just for the duration. Is this structure, where the AttributeAssignment is a part of the Production something that is accepted or to be phased out? I notice that that section no longer renders properly in the website view for example.

In short, do we use the assigned_by (first example) or the part (second example)?

       "part": [
          {
            "type": "Production",
            "_label": "Production",
            "id": "component/14eadd10-c8ae-5fca-9a96-66c4072996e9/agent-activities/1",
            "carried_out_by": {
              "id": "person/f4833761-9369-53b6-9693-5ab78a058f48",
              "type": "Person",
              "_label": "Jackson, David"
            },
            "assigned_by": [
              {
                "type": "AttributeAssignment",
                "assigned_property": "classified_as",
                "assigned": [
                  {
                    "id": "http://id.loc.gov/vocabulary/relators/pht",
                    "type": "Type"
                  },
                  {
                    "id": "http://vocab.getty.edu/aat/300404670",
                    "type": "Type",
                    "_label": "preferred terms"
                  }
                ],
                "assigned_to": {
                  "id": "person/f4833761-9369-53b6-9693-5ab78a058f48",
                  "type": "Person",
                  "_label": "Jackson, David"
                }
                ]
              }
            ],
            "technique": [
              {
                "id": "http://vocab.getty.edu/aat/300054225",
                "type": "Type",
                "_label": "photography (process)"
              }
            ]
          },

       "part": [
          {
            "type": "Production",
            "_label": "Production",
            "id": "component/14eadd10-c8ae-5fca-9a96-66c4072996e9/agent-activities/1",
            "carried_out_by": {
              "id": "person/f4833761-9369-53b6-9693-5ab78a058f48",
              "type": "Person",
              "_label": "Jackson, David"
            },
            "part": [
              {
                "type": "AttributeAssignment",
                "assigned_property": "classified_as",
                "assigned": [
                  {
                    "id": "http://id.loc.gov/vocabulary/relators/pht",
                    "type": "Type"
                  },
                  {
                    "id": "http://vocab.getty.edu/aat/300404670",
                    "type": "Type",
                    "_label": "preferred terms"
                  }
                ],
                "assigned_to": {
                  "id": "person/f4833761-9369-53b6-9693-5ab78a058f48",
                  "type": "Person",
                  "_label": "Jackson, David"
                }
                ]
              }
            ],
            "technique": [
              {
                "id": "http://vocab.getty.edu/aat/300054225",
                "type": "Type",
                "_label": "photography (process)"
              }
            ]
          },

[kkdavis14]

Antonio/AAT agreed to add 300456575 as sort values with LUX as the source.

As usual, not live for a few weeks til they publish new data.

[azaroth42]

Sort Value is public in AAT and in the required vocab list. I pulled the sort identifier model docs from archives up to collections.

[azaroth42]

@benosteen

I would just follow the pattern here: https://linked.art/model/object/production/#multiple-artists-with-different-roles which doesn't use an attribute assignment at all. The only reason to add an attribute assignment is if you want to classify the assignment with a probably / possibly and have it distinct from the main set of roles carried out for indexing purposes (e.g. index all the main ones in part and either not index the attributed ones or index them separately)

So:

...
  "produced_by": {
    "type": "Production",
    "part": [
      {
        "type": "Production",
        "technique": [
          {
            "id": "http://id.loc.gov/vocabulary/relators/pht",
            "type": "Type",
            "_label": "photographer"
          }
        ],
        "carried_out_by": [
          {
            "id": ".../person/f4833761-9369-53b6-9693-5ab78a058f48",
            "type": "Person",
            "_label": "Jackson, David"
          }
        ]
      }
...

[azaroth42]

Added notes to the above effects to docs.