Do we need three levels of types in the occupation pattern?

[stephenhart8]

For the moment, in the v1.5 TM, the occupation have three level of types. The first E55 Type is to type what kind of occupation the Actor is doing (Painter, Woodworking, etc.) The second E55 Type would be type if this occupation is an profession, industry field, leisure, etc. (a controlled vocabulary would obviously be needed) The thirst E55 Type would be to type that this is an occupation.

There's an example to explain that:

Is there a level of E55 Type that is not needed?

[KarineLeonardBrouillet]

In my opinion, all three are necessary and logically follow from the most precise to the broadest so I don't think I would remove any of them.

[stephenhart8]

In a comment by George @Habennin , he suggested to use the property R59 had typical subject instead of the first E55 Type as the scope of F51 Pursuitsuggests:

This property associates an instance of F51 Pursuit with the instance of E1 CRM Entity that is the typical subject of the associated activity, such as an area of expertise in which the actor is engaged or was engaged.

With the example used in the documentation: John Dover Wilson’s activity as a Shakespeare scholar (F51) R59 had typical subject William Shakespeare (F10)

But in my opinion there is a difference between the type of activity, and the subject of the activity, as shown in the example given by the FRBRoo documentation.

[Habennin]

The three levels of types looks... scary. Actually it's fine if it's a vocabulary because then you can control that all with SKOS and just point to the most relevant entry.

I don't remember the precise content of my suggestion but I don't think you capture it above. I would suggest using a E51 Pursuit activity to model the occupation if you have temporal data (like when a company formed and ended). Then you can use F51 Pursuit and it gives you more flexibility.

I have attached my model below. I don't think there is a need for the third level, since being in industry is not an occupation. That being said, if you wanted a third level, why don't you organize all this in a SKOS vocabulary and then just use the mechanisms that you have available there.

[stephenhart8]

I would agree with you @Habennin the R59 seems a nice addition. I would just add another level on the Industry types, as follows:

[illip]

I'm not against using R59 but I don't think it's necessarly solving the third level issue as @Habennin pointed out. If you keep the KODAK example, we might need to express "Photographic Materials" R59 -> E55 but also "Photography" P2 -> E55 (Photography) -> P2 ->E55 (Industry).

I agree with George that we should keep a two-level E55 pattern and use external SKOS vocabularies to fill them. The first level should be the "nature" of the event and the second one the "descriptor" of the "nature". To request a broader term, we will need to refer to the external SKOS vocabularies.

All this to say that I would suggest to have three distinct SKOS vocabularies to support this example. Such as:

[stephenhart8]

I don't really understand why you are using 3 distinct SKOS vocabularies it that case, but we could discuss it some time when we meet @illip

Would that mean that if we wanted the occupation of every actors, we could do a SPARQL request that searches every skos:concept "Occupational Activity" (and narrower terms) that are linked to the F51 Pursuit?

It seems reasonable to use SKOS rather than long chains of E55 Type, but that would need to go though out the model and see where we would need SKOS vocabulary

[illip]

@stephenhart8 The number of vocabularies depends on the scope of each one. I don't know what is the best approach but the question of alignment was raised at the last Linked.Art meeting. The issue is close to ours and it's about the fact that Linked.Art will generate a new hierarchy with e55->p2->e55 pattern which diverges from the AAT's one.

The issue: https://github.com/linked-art/linked.art/issues/296 You can also have a look at the minutes (which are more relevant, I think): https://docs.google.com/document/d/1u0Mp7gyBKe4A_2qEXxEGm0ye1OkXYiw4hQ0kgbZETL0/edit

For the second part of your post, I would simply say "yes". All the vocabularies/thesaurus should be managed in SKOS and then we could combine two skos:Concept in our e55->p2->e55 pattern.

[Habennin]

responded, I hope, on issue 37

[illip]

@stephenhart8 I think we should close this issue. Modeling-wise, I think we all agree that we don't need a third level of E55. However, might be interesting to have another issue to discuss the vocabularies management?

[stephenhart8]

Yes, I am closing it, and we will create a new Issue on the vocabulary topic.

[stephenhart8]

As the update of the three levels of E55 Type has not yet been done in the TM 2.1, I am reopening the issue as the reminder, and will close it again once the TM will be updated

[illip]

The current CHIN's proposal on this issue is:

1. Never use more than two levels of E55_Type.
2. Where we currently have a three-level structure in the TM, we will remove the middle E55_Type. If the latter is relevant in our model, this would mean that we need a new pattern to represent a more specific meaning.
3. We will rely on external SKOS vocabularies (made by CHIN or not) to retrieve more generic terms. To do so, we will need to think about relevant queries for our stakeholders and ensure that the external vocabularies will be developed accordingly.

In the TM we currently have two patterns that use this structure:

• Occupation
• Social Status

We will validate this proposal with our Semantic Committee on January 7th.

[illip]

All the aforementioned items have been approved by the Semantic Committee on 2021-01-07.

[TrangDg]

The text and diagrams have been amended according to the final decision.

• Removing second level;
• Change nodes "Occupation" to "Occupation Type" and "Social Status" to "Social status Type".