NPGExhibitions:ExhTitle

[steads]

ExhTitle: This is correctly mapped from the exhibition (an instance of E7 Activity). The full path would then be:- E22 ->P16i ->E7 [Exhibition] ->P1 -> E41 ->P16.1 ->E55 {Exhibit}

[rhao]

I added the full path to include E22.

Wouldn't it make more sense to have the E55 (string literal "Exhibit") be the type of the Exhibit (represented by E7_Activity), as opposed to E22 was used for E55 ("Exhibit"), because we also have the E7_Activity instance which represents the Exhibit? So connecting both E55 and E7 to E22 with P16i almost seems like you're duplicating the Exhibit.

My proposal: E22->P16i->E7->P2->E55 As opposed to: E22->P16i->E55 and E22->P16i->E7

[workergnome]

Rebecca, I think the distinction is between P16i and P16.1, AKA p16-the-letter-i, and p16-dot-one.

P16.1 is the property-of-the-property mapping, which is to say that it is:

"The Object (E22)"..."Was used for (P16i)"..."The Exhibit (E7)"..."with the mode of use (P16.1)"..."Exhibition Object (E55)"

as well as "The Exhibit (E7)"..."Is Identified By (P1)"..."an appellation (E41)"

[rhao]

Ah yes, I missed that distinction, thanks. In the CIDOC-CRM documentation, it says that P16.1 is a property of E7, to connect to E55 (E7->P16.1->E55), so maybe it should be this? E22->P16i->E7->P16.1->E55.

Or do you think it's fine to do E22->P16.1->E55 and E22->P16i->E7, as originally suggested? When you write out the semantic meaning, I think it makes more sense to tie it to E22 as originally suggested, but I want to be careful not to violate the ontology.

[steads]

The CRM does not say that P16.1 is a property of E7: It says that P16.1 is a property of a property: that is the domain is an instance of the P16 property and its range is an instance of E55 Type. This construct is used to provide dynamic sub-typing of properties where that is required. It is described in the Terminology section under properties. So it is NOT E22->P16i->E7->P16.1->E55 NOR is it E22->P16.1->E55 and E22->P16i->E7. It is E22 ->P16 ->E7 then from the P16 ->P16.1 ->E55

[workergnome]

Hi, all.

@steads is correct. The CRM, as a conceptual model, uses properties of properties. Unfortunately, RDF, which is the way in which we are implementing the CRM, does not allow properties of properties to be directly linked.

We've been having a vigorous discussion as to the proper way to implement this. I believe that our current best practice is to use CRMpc to reify this, which means that instead of going directly from E22->P16i->E7, instead we're going to insert an entity between them.

the CRMpc see this attached file contains the properties and classes that we would need to implement this.

For this example, we would use it like this:

Given these three entities:

_:the_object a crm:E22_Man-Made_Object.
_:the_exhibit a crm:E7_Activity.
_:the_use_type a crm:E55_Type.

We would connect them like this:

_the_usage a crmpc:PC16_used_specific_object;
  crmpc:P01_has_domain _:the_object;
  crmpc:P02_has_range _:the_exhibit;
  crmpc:P16.1_mode_of_use _:the_use_type.

Instead of a straight:

_:the_object crm:P16i_was_used_for _:the_exhibit.

Because there's no way in RDF to directly attach the type to crm:P16i_was_used_for.

Does that make sense?

[rhao]

Great, makes sense, I mapped it as described above using the attached CRMpc file. Let me know (once I upload it) if it's what you intended!

[VladimirAlexiev]

Despite what Steve says, CRMpc is not used in any dataset that I am aware of. Also, I am not sure that it is approved by the SIG in an official way. Searching on google for "CRMpc rdfs" and "CRMpc site:www.cidoc-crm.org" doesn't turn up the above file. At least, P01_has_domain must be renamed to P01_has_subject and P02_has_range must be renamed to P01_has_object: domain and range are Classes not Individuals.

There is a way to express such reification using the main CRM standard: E13_Attribute_Assignment.

No matter which way of reification you select, please emit the direct statement. Otherwise no app that speaks CRM only will find your statement.

@azaroth42, what do you think?

[azaroth42]

Agreed -- sticking to the core whenever possible rather than expanding into extensions increases the likelihood of interoperability and adoption.

From the meeting at ISI, it did seem that the mapping was going to be frozen regardless of how good it is currently. I think these fixes will have to come in a second round of work, if that happens, and the experiences written up as lessons learnt about the process we've gone through.