Add hasStylePeriod and isStylePeriodOf predicate to core.owl

[rjyounes]

Needed: class StylePeriod, predicates hasStylePeriod and isStylePeriodOf.

Note: hasStyle is already included (though not the inverse - this should also be defined as isStyleOf).

[sfolsom]

Do we need a class/range or can we leave it open? We'll likely be linking to/using/contributing to skos:Concept vocabularies like AAT for these, like in the SHACL.

[rjyounes]

We're going to add a class StylePeriod but not specify it as range or domain of the predicates - these should remain open to allow use of other vocabs

[rjyounes]

Define StyePeriod as subclass of skos:Concept.

[sfolsom]

Defining the term as a subclass of skos:Concept seems like a new direction as compared to the other classes defined in ARM. If it's just a subclass of skos:Concept, we don't need it, especially if we're reusing skos:Concepts from Getty where they have a defined hierarchy for Style/Periods. The only reason to define the class would be if we decided we need to be able to create non-skos Style/Period entities.

[rjyounes]

I'm assuming the ontology does not dictate which vocabularies should be used in producing instance data.

[sfolsom]

Right, That's why we have an application profile. Are you suggesting we mint a class we wouldn't use in case someone else using the property wants to use/create a different vocabulary?

[rjyounes]

Yes, I am. The ontology is distinct from the application profile and shouldn't be dependent on the particular profiling choices we've made, IMO. I believe the dependency goes in the other direction. I'm not sure I understand who "we" is. There's "we" the ontology creators, and "we" the ontology implementers. Two separate groups, even if they happen to be composed of the same people, though of course their concerns overlap and intersect.

[rjyounes]

Another observation: this pattern is actually in keeping with other patterns we (and LC) have developed, where we define a class as a container or umbrella and use vocabularies to add precision. An example is Binding. This way rdf:type can return some meaningfully results, but we do not try to replicate the vocabulary in a class hierarchy.

[sfolsom]

It was defining it as a subclass of skos:Concept that was a departure from classes like Binding. I agree that in many cases we have defined Classes for conceptual types of things and then classified them using crm:P2 and external SKOS vocabularies (which isn't the same as making a new class that is the subclass of skos:Concept and then trying to use crm:P2 to further differentiate the concepts).

[rjyounes]

Maybe I'm misunderstanding, but where in the modeling recommendation does it get defined as a subclass of skos:Concept?

[rjyounes]

It just occurred to me that there is a significant difference between this and the Binding case: one might assert the existence of a Binding on a resource (i.e., :x bf:hasPart :binding . :binding a arm:Binding) without adding further type specifications through the vocabulary, whereas asserting that something has a StylePeriod without specifying which StylePeriod has no utility. In the end I'd say we can go either way and I'll add it as a topic for future research whether we want to include it or not.

[rjyounes]

StylePeriod class removed - no provable utility.

[melanieWacker]

I hate to open a long-closed issue, but I am mapping ArtProperties to ARM and discovered a use case for the arm:StylePeriod class. Without the class, there is nothing I could hang a bf:note or rdf:value off of.

[rjyounes]

It sounds like this is similar to arrangements in the measurement model. At Steven's suggestion, I recently modified the model to include an arrangement resource which is typed both as rdf:type arm:Arrangement, and crm:P2_has_type arm:folded (etc.). This provides a resource for the MeasurementGroup to hang off of. It sounds like you're proposing following this model for StylePeriod - i.e., rather than linking directly to the style/period vocabulary term with hasStylePeriod, we'd have a resource that is rdf:type arm:StylePeriod and crm:P2_has_type . Am I understanding you correctly? Just out of curiosity, what sorts of data do you want to attach to the StylePeriod resource?

[melanieWacker]

Yes, that sounds like what I had in mind. I am looking at data such as "Muromachi to Momoyama periods" or "Ming or Qing dynasty" so I can't link to a specific vocabulary term.

[rjyounes]

Update recommendation doc accordingly

[VladimirAlexiev]

Two observations:

• most AAT styles come under the Styles and Periods hierarchy, but not all. Getty CONA uses other items in its "hasStyle" fields, eg ethnicity/nationality (eg a Maya stone inscription), dynasty (eg a Ming vase) or religion (eg a Christian Orthodox icon)
• StylePeriod matches crm:E4_Period, which is quite different from crm:E55_Type. But I think this strict CIDOC CRM distinction is not useful in practice, because eg AAT concepts are used in various kinds of contexts, and sticking to strict range restrictions would force them to be incompatible CRM types.

So overall, I think it's enough to use skos:Concept in this case and there's no need for separate StylePeriod class.

@melanieWacker the case you describe can be modeled thus:

  hasStylePeriod [a skos:Concept; skos:prefLabel "Ming or Qing dynasty"]

To facilitate discovery, you should index it to AAT

  hasStylePeriod [a skos:Concept; skos:prefLabel "Ming or Qing dynasty";
    skos:narrowerMatch
      aat:300018438, # Ming (culture, period, and styles)
      aat:300018478. # Qing (dynastic styles and periods) 
]

skos:narrowerMatch is logically correct, but a bit surprising for people, so you can replace it with skos:closeMatch

Or you could simplify by disregarding the distinction between conjunction and disjunction:

  hasStylePeriod 
      aat:300018438, # Ming (culture, period, and styles)
      aat:300018478. # Qing (dynastic styles and periods) 

@rjyounes It's important to document these usage patterns in an application profile, or even express them in machine-readable way as RDF shapes (SHACL or ShEx). Else, as @american-art experience shows, every museum uses their own way of mapping, which doesn't lead to interoperability.

In my experience, semantic modeling includes as much (or even more) Shape building as Ontology engineering.

[VladimirAlexiev]

Sorry, I see from https://github.com/LD4P/arm/tree/develop/application_profiles/art/shacl that I'm preaching to the preacher. But there are still too few shapes. Cheers!

[melanieWacker]

Thanks @VladimirAlexiev . This is helpful input. And yes, more documentation both in human readable form and in SHACL is still to come.

[rjyounes]

@melanieWacker Given the new profiling:

:work arm:hasStylePeriod :style_period .
:style_period a :StylePeriod ;
    crm:P2_has_type aat:300172863 .

it seems we can now define the domain (range) of arm:hasStylePeriod (arm:isStylePeriodOf) as arm:StylePeriod. In the previous model, arm:hasStylePeriod pointed directly at the taxonomy term, which could not be asserted to be an arm:StylePeriod. Do you agree?

[melanieWacker]

Yes, it it more consistent with other areas of the arm model (e.g. materials)

[rjyounes]

ARM actually provides models of both types (i.e., a predicate that points to a resource of a specified type that may have other properties, including crm:P2_has_type, or a predicate that points directly to a taxonomy term). For example:

1. The measurement model uses arrangement resources of type arm:Arrangement, crm:P2_has_type arm:folded (for example), so that measurements can be attached to that resource and not to the taxonomy term (thanks to @sfolsom for pointing out the need for this).

2. In the modeling of materials, status, origins, and so on, the predicate in question points directly to the vocabulary term, since we don't expect to have additional assertions to make about the status or material individual.

It may be that 2 is a bad pattern, in that we would always want to leave room to attach notes or other information to the individual - e.g., noting who assigned a particular status, or when that status became applicable. In the case of materials, you may have resources for which no term exists, as in your StylePeriod examples above.

There's a hybrid approach where we would allow for either possibility - so in the case of StylePeriod, a nonce StylePeriod resource that crm:P2_has_type aat:300172863 (as above), OR pointing arm:hasStylePeriod directly to aat:300172863 (as in the original model). Then we run into the issue of lack of uniformity of profiling and querying.

I will put this all into the areas for future research document - it's certainly too big an issue to tackle now. In the meantime, I think it makes sense to add the StylePeriod class but leave the domain and range off the predicates; this will give users maximum flexibility until these issues can be settled.

@melanieWacker Does this work for you? Do you have a better suggestion?

[melanieWacker]

Agreed. Thanks

[VladimirAlexiev]

Sorry folks, the above is inconsistent. What's the difference between

a :StylePeriod; rdfs:label "Ming"

and aat:300018438 (used for :hasStylePeriod)? Very little if any: one is an ad-hoc concept, the other is a concept taken from a vocabulary.

So you can't link the two with P2_has_type, which is intended to connect a specific (eg a painting) to a generic (a concept).

You could say

a :StylePeriod; rdfs:label "Ming"; skos:exactMatch aat:300018438

but that is wasteful, better say just aat:300018438. It's not hard to account for that difference in queries:

?object :hasStylePeriod/(skos:exactMatch?) ?style

room to attach notes or other information to the individual - e.g., noting who assigned a particular status, or when that status became applicable

Ah, but then you're talking of an Attribute Assignment, which is an Activity.

[rjyounes]

@VladimirAlexiev As we wrap up the project, we are working on documentation of areas for future research, which will include detailed discussion of these issues and may interest you. That will appear in the repository during the next week or so.

I will note that the domain of crm:P2_has_type is crm:E1_crm_entity, a class that comprises "all things in the universe of discourse." Without speaking to whether the authors' intended use includes the example above, the definitions do not appear to formally preclude it.

[VladimirAlexiev]

@rjyounes Thanks! Any mapping of GLAM/museum data to RDF is of great interest to me. Eg I'm doing consulting for CA-CHIN and we're wondering between:

• CIDOC CRM (ala ResearchSpace)
• linked.art (ala AAC)
• schema.org (plus extensions like bib.schema.org)
• Wikidata (ala project Sum of All Paintings)

So I learned with a lot of interest of your additions to BibFrame.

---

Yes, P2 can be applied to any CRM entity, to characterize it according to some E55_Type (which is nearly the same as skos:ConceptScheme, i.e. a thesaurus). But P2 doesn't mean "same". And when you say

a :StylePeriod; rdfs:label "Ming"; crm:P2_has_type aat:300018438

you do mean this local StylePeriod is the same as that AAT concept.

[rjyounes]

@VladimirAlexiev OK, point taken re crm:P2_has_type.

So we have these two cases:

Case 1. We can identify the style/period of the resource with a vocabulary term:

:resource arm:hasStylePeriod aat:300018438

Case 2. We cannot identify the style/period of the resource with a vocabulary term:

:resource arm:hasStylePeriod :style_period .
:style_period a arm:StylePeriod ; # or simply skos:Concept 
    rdfs:label "Ming or Qing dynasty" ;
    # And additionally use a skos predicate to indicate relationship(s) to vocabulary term(s).

This case would also be applicable if we had additional data to assert about the :style_period resource. In the case of style/period I don't believe that's the case, but that's the pattern we see in, for example, our modeling of measurements of particular arrangements of an item: https://github.com/LD4P/arm/blob/master/modeling_recommendations/measurements.md.

The query pattern is as you show above, with whatever the appropriate skos predicate is.

I like the use of skos:narrower for disjunction in your example above. I'm not sure whether the intent of a range, as in Melanie's example "Muromachi to Momoyama," is also to express uncertainty, or whether it literally means the style/period of the work belongs in the Muromachi and Momoyama periods, and all periods in between. That seems difficult to express.