Using the Thing type for nested performer entities

[fjjulien]

A growing number of performing arts organizations are describing performer entities in their structured data. This is great thing!

However, @dlh28 @MorganPann and I, occasionally stumble upon sites where the same default type appears to be used for all performers. For example, the Fredericton Playhouse and the Imperial Theatre are using the Person for all their performer entities. This can lead to inaccurate data, as can be seen in this example.

If an arts organization does not have the capacity to customize the performer type for each event, should we be recommending that they use the type Thing as their default value?

Schema's documentation says that the expected values for the performer property are Person and Organization (or sub-types thereof). And Person and Organization both are direct subtypes of Thing. Therefore, stating that a performer entity has the type Thing would not be inaccurate.

Of the two evils, which is the least? Using a broader but correct type? Or using a narrower yet wrong type?

And could the Thing type trigger constraint violations in systems that only allow Person and Organization?

@saumier Please advise.

[saumier]

@fjjulien I have also come across this problem many times. The schema.org doc says that range for schema:performer is schema:Person and schema:Organization including sub-types. A sub-type is more specific like a schema:PerformingGroup. The schema:Thing is not a sub-type of schema:Person or schema:Organization. I don't know why the schema.org validator is not showing a performer of type schema:Thing as an error.

If only there was an Agent like entity that could include both schema:Person and schema:Organization, but sadly there is not.

My approach is currently to try to reconcile the performer entity with Artsdata when minting, and then use the Artsdata entity type instead of the supplied performer type. This can 'correct' the problem when there is a match.

[saumier]

I prefer https://schema.org/PerformingGroup if the performer type is unknown. A group could be a solo artist.

[fjjulien]

If schema:PerformingGroup is a subclass of schema:Organization, then a solo artist should not be given that type. This will unavoidably lead to issues down the road.

[fjjulien]

As discussed in this discussion thread, many external classes can be used to denote an "agent" type. Anyone of these could be used as an additionalType in conjunction with the Thing type.

[fjjulien]

J'ai décelé un problème avec le type PerformingGroup lorsqu'il est associé à un artiste individuel.

Si un artiste a le type PerformingGroup dans un jeu de données et le type Person dans un autre, l'API de réconciliation d'Artsdata n'arrive pas à établir un match. Par exemple, dans le jeu de données de Scènes francophones, certains artistes ont à la fois le type PerformingGroup et le type Person, l'API de réconciliation tente de réconcilier contre des entités de type Organization (classe parent de PerformingGroup) et ne trouve pas l'ID Artsdata du même artiste qui est pourtant là, mais avec le type Person.

Vous pouvez faire un essai avec P'tit Belliveau https://scenesfrancophones.ca/id/252 : on n'arrive pas à réconcilier avec P'tit Belliveau ad:K12-387.

Conclusion : À moins que nous ne trouvions une solution à ce problème de réconciliation, il est sans doute préférable de ne pas utiliser le type PerformingGroup par défaut pour toutes les entités artistes imbriquées sous schema:Performer.

[saumier]

@fjjulien When the source data mixes up the type of artist as a Person or Organization or both, then you should use use dbo:Agent to reconcile. The scenefrancophones.ca website defines P'tit Bellivea as a Person on their bio page and a PerformingGroup on the event page,

In your example above, the Artsdata reconciliation API will reconcile with P'tit Belliveau using dbo:Agent because it includes both Person and/or Organization.

The issue you are having is related to the User Interface of Artsdata (Nebula) that does not automatically set the reconciliation type to dbo:Agent or allow you to change the reconciliation parameters. I propose an enhancement in Nebula to set the dbo:Agent when reconciling either Person or Organization, and also allow the user to manually change the reconciliation parameters (name, type, date, location, postal code, etc.) to broaden/narrow the reconciliation matches when trying to link to an existing entity. This enhancement will solve a lot of different cases, such as when the postal code is wrong but you still want to reconcile to an existing place.

Conclusion : À moins que nous ne trouvions une solution à ce problème de réconciliation, il est sans doute préférable de ne pas utiliser le type PerformingGroup par défaut pour toutes les entités artistes imbriquées sous schema:Performer.

@fjjulien I still think the use of type PerformingGroup is a good choice when the performer is not know to be a Person or a Group. The use of PerformingGroup is unrelated to the problem case described above with P'tit Bellivea. I recommend type PerformingGroup instead of using Thing by default. We know for sure that the performer is not a object like a CreativeWork which is a Thing.

[fjjulien]

@saumier Merci beaucoup pour ton analyse et ta réponse rapide.

I notified RADARTS and I supplied a recommendations document for their developer.

[fjjulien]

The issue you are having is related to the User Interface of Artsdata (Nebula) that does not automatically set the reconciliation type to dbo:Agent or allow you to change the reconciliation parameters. I propose an enhancement in Nebula to set the dbo:Agent when reconciling either Person or Organization, and also allow the user to manually change the reconciliation parameters (name, type, date, location, postal code, etc.) to broaden/narrow the reconciliation matches when trying to link to an existing entity. This enhancement will solve a lot of different cases, such as when the postal code is wrong but you still want to reconcile to an existing place.

I like this idea. Let's make a mental note of this and include these interface feature in the upcoming work order for the update of the reconciliation API.

[fjjulien]

Even though Artsdata's interface could be adapted to enable human-assisted reconciliation against a different type than what is stated in the source, this solution would not get us any closer to developing a capacity to automatically reconcile performer entities.

I've considered this issue over and over, and I still come to the conclusion that recommending the use of schema:PerformingGroup as a default type - knowing that this would yield a large number of inaccurate instantiations - is a poor solution.

I re-read Schema.org's decision for not declaring an Agent class and I found support for using schema:Thing when the precise type of an entity cannot be defined.

In his opening statement, @danbri stated the following as an argument against the creation of the agent class:

Schema.org already supports the representation of ignorance through simple ommission. There is no need to decide whether something is a Person or Organization if you don't know - simply omit a type. This is supported in RDFa and JSON-LD and other RDF syntaxes. In Microdata, Thing can be used if needed within some syntactic settings.

Further down, as a concluding comment, a contributor in favor of the declaration of the Agent class, rallied with the community and proposed this alternative solution:

The recommended path for those wishing to reflect an Agent in their data would be to identify it as a type schema:Thing. Any further qualification should be with terms from other vocabularies such a foaf:Agent dct:Agent etc. in addition to schema:Thing

Based on the above information, I am proposing the following Artsdata guidelines for performer types:

---

In situations where it is not possible to assign a specific type to a performer value, Artsdata recommends the following modelling for the nested entity:

    {
        "@type": "Thing",
        "additionalType": [
            "http://dbpedia.org/ontology/Agent",
            "http://xmlns.com/foaf/0.1/Agent",
            "http://www.cidoc-crm.org/cidoc-crm/E39_Actor"],
        "name": "--Nom de l'entité : Name of the entity--",
        "sameAs": ""--URI Artsdata.ca, obtenue avec l'API de réconciliation ou l'outil de recherche : Artsdata.ca URI, obtained with the Reconciliation API or the search tool--"
        }

[fjjulien]

@saumier Can you please reconsider this issue in the light of Schema's consensus regarding unkown types and the Agent class?

[fjjulien]

@saumier How would entities classified as "@type": "Thing" be displayed in Artsdata's "Data sources" list?

The interface only lists 4 groups of entities: events, orgs, people and places. A Thing type entity would fall in none of these categories and would therefore not be displayed at all in the Nebula interface.

RADARTS implemented this solution in Scènes francophones as a fallback type for "Artiste" entities when a presenter user creates an event and the performer entity is not already present in the database. I was hoping to give these entities a proper type within Artsdata. However, it won't be possible if we can't select them in the interface.

[saumier]

@fjjulien Good question.

The interface only lists 4 groups of entities: events, orgs, people and places. A Thing type entity would fall in none of these categories and would therefore not be displayed at all in the Nebula interface.
The "Data Feeds" screen is a SPARQL query and it currently columns with a link to view events, orgs, people, place. This could be changed to include a column for "all" but I am not sure if that is goos.

It is currently possible to reconcile performers in scenefrancophones but you need to select the artists with type "Thing" by going into an event, selecting the performer, clicking "mint", and then linking it to a existing person or artist in Artsdata. Currently all entity types are shown in the reconciliation list because all entities are Thing (or resource) so you need to be careful because it includes many events which may have the same name as the artist.

It is currently possible to reconcile, but to make it easier to reconcile all artists from a source like Scènes francophones, a SPARQL called "reconcile performers" could be added to list all the performers that are not reconciled (minted or linked) in a source.

I noticed that scenefrancophones is adding some additionalTypes, so another way is to start with dbo:Agent in Artsdata or E39_Actor in Artsdata and work the list of derived entites from scenesfrancophone.

It is NOT currently possible to mint an artist "thing". This would need the minter to have the option to select an override for the type. This is a small amount of work.

The other approach that I had suggested when the performer is unknown is to use scheme:PerformingGroup which is a sub-type of Organization and would appear in the column.

Let me know if I answered your question.

[fjjulien]

@saumier Merci pour ta réponse.

Scènes francophones a remplacé les legacy PerformingGroup type par Thing. J'ai donc été en mesure d'attribuer des identifiants aux représentations de P'tit Belliveau et de réconcilier l'entité P'tit Belliveau imbriquée dans la représentation.

I'm now however accutely aware that we cannot view or mint "Thing" entities in Artsdata... :(

As a potential solution for displaying "Thing" entities in the list of data sources: we could group them under "other". To be discussed...

No further action required on your part for now.

[fjjulien]

If the community agrees with the above recommendation, I propose deploying it as part of a series of edits and new documentation page publications. Here is a proposed deploying plan.

---

Artsdata-specific instructions for the schema:Performer property

Location: Artsdata-specific instructions exist in two places: in the Event Class page (contents are pulled from a linked Google Sheet) and in the Event structured data template page. Both the Google Sheet and the page should be updated.

Current version:

en: “Enter information identifying and describing the company, group or person(s) delivering the performance. Recommended properties for the nested entity include: name, url, and sameAs (with link pointing to an ISNI, Wikidata or Artsdata URI).”

Proposed edit:

"Enter information identifying and describing the main company, group or person(s) delivering the performance. Recommended properties for the nested entity include: name, url, and sameAs (with link pointing to an ISNI, Wikidata or Artsdata URI). For further guidelines, see: <hyperlink_to_new_guidelines_page_below>."

---

Artsdata guidelines regarding the performer property

New documentation page to be created

The performer property provides extremely valuable information about a performing arts event. For example, it can be used to retrieve other performances by the same performer entity or to filter events based on the origin of the performer.

Good practices for selecting performer values

See: < hyperlink to a new guidelines page based on #142 >

Good practices regarding performers' @type

Determining whether a performer should be assigned the Person, PerformingGroup, or Organization is not a always a straightforward task.

Confusion often arises when a solo artist is performing along with other musicians whose names are not specified.

Let's take an example: Susan Aglukark ad:K12-296 is touring along with four musicians, but we don't know who they are, and they may even change from one performance to another. In such a case, is the performer entity a Person or a PerformingGroup?

If the name of the performer entity is the name of a physical person, then the type should be Person.

Here's why.

PerformingGroup is a subclass of Organization and has no direct or indirect relationship with the Person class in the Schema.org ontology. Consequently, if the type were PerformingGroup, search engines, Artsdata and other user agents reading the data will attempt to reconcile the name string - "Susan Aglukark" in the above example - against other PerformingGroup or Organization entities in authority files. Since Susan Aglukark is considered a Person in Wikidata, Musicbrainz, VIAF and ISNI (and Artsdata), they may not find a match.

In other words, if you want your structured data to make sense for machines, you should use the same type as one would find in authority files such as Wikidata and VIAF.

In situations where it is not possible to assign a specific type to a given performer entity or if you wish to define a default type that will be true for all performer objects, Artsdata recommends the following modelling for the nested entity:

    {
        "@type": "Thing",
        "additionalType": [
            "http://dbpedia.org/ontology/Agent",
            "http://xmlns.com/foaf/0.1/Agent",
            "http://www.cidoc-crm.org/cidoc-crm/E39_Actor"],
        "name": "--Nom de l'entité : Name of the entity--",
        "sameAs": ""--URI Artsdata.ca, obtenue avec l'API de réconciliation ou l'outil de recherche : Artsdata.ca URI, obtained with the Reconciliation API or the search tool--"
        }

In this proposed modelling, the "Agent" and "Actor" additional types are classes designating "an entity that acts", and are super classes to persons, groups and organizations. The Artsdata reconciliation server enables reconciliation against the dbo:Agent class.

Even though Thing is not an expected type for objects nested under the performer property in Schema.org, the Schema community deems it acceptable to use a broader type (or to omit the type altogether), when a narrower type cannot be defined (read more).

In conjunction with the use of Thing as a default broader type, we recommend providing a sameAs to an Artsdata ID. If the performer object has Thing as the default broader type, and it also has a sameAs to an Artsdata ID (where a narrower type is always stated), then search engines can compare the two data records and choose to use the narrower type for the performer entity.

Good practices regarding performers' sameAs

See: How to retrieve persistent identifiers' URIs

---

Artsdata good practices for selecting performer values

The current discussion should be finalized and a definitive answer should be provided.

---

Artsdata dbo:Agent document page

New documentation page to be created

dbo:Agent - DBpedia Ontology (details)
Dbpedia definition: Analogous to a foaf:Agent, an agent is an entity that acts. This is intended to be the super class of Person and Organisation.
subclassOf: owl:Thing
Is subclassOf of: ado:Person, ado:Organization

Use of dbo:Agent in the Artdata data model

dbo:Agent can be used in conjunction with the Artsdata reconciliation service to enable reconciliation against both ado:Person and ado:Organization type. This is particularly useful in situations where the value of a given property can be either a person (e.g. a solo artist), a group (e.g. a music band or a collective), or an organization (e.g. an artistic company).

Recommended use of dbo:Agent in the performing arts domain

dbo:Agent (and other Agent-like classes) can be useful for properties whose range can be either a Person or Organization type object. The most notorious property in this regard is undoubtedly performer. For more information on this particular case, see : <link_to_performer_guidelines>.

[dlh28]

Looks good to me

[fjjulien]

Update from @MorganPann

Hello! I published these two pages on GitHub yesterday:

Artsdata Guidelines Regarding the performer Property: https://culturecreates.github.io/artsdata-data-model/performer-property-guidelines.html

Good Practices for Selecting performer Values: https://culturecreates.github.io/artsdata-data-model/performer-values.html

Please give them a look and relay any suggested edits.