Issue 588: Common Policy / Method for Implementing the .1 Properties of Base and Extensions in RDF

Starting Date: 
Working Group: 

Post by George Bruseker (22March 2022)

Dear all, I am wondering if we should have somewhere in the main document where you can find all the .1 properties. Presently, to my knowledge, there is no index of where these properties are. For those that use the .1 properties it is difficult to find them all using the specification document. One cannot search for '.1' as this returns too many results.

What do people think?



Post by George Bruseker (23 March 2022) 

Dear all,

I am also wondering about implementing .1 constructs in CRM Archaeo. Although CRM Archaeo declares .1 properties that are actually essential to its implementation, those properties are not (I believe) expressed in the RDF that comes with CRM Archaeo. Is there a hidden PC file for CRM Archaeo or does everyone generate their own? Should it have an official version? This seems important in terms of the property classes being given the same nomenclature etc or interoperability. 

Maybe I missed them on the site.



Post by George Bruseker (24 March 2022)

Dear all,

Subsequent to another thread I started here I am proposing that there be a conversation about having a standard policy and method for creating, documenting and making available the .1 properties for base and its extensions in the RDF serialization. At present to my knowledge the PC classes are only available for CRMBase and relative to version 6.2.1. Other extensions however also use .1 constructions and, moreover, CRMbase moves forward and its PC classes should hypothetically move with it. Therefore, I propose we discuss, create and implement a common policy for creating this rdf derivative to support rdf implementations that adopt the .1 constructions.



Post by Pavlos Fafalios (24 March 2022)


Dear George, all,

The new version of PC classes file (for CRMbase version 7.1.1) has been already produced (as discussed in the last meeting) and will be soon available through the crm website (see issue 567). 

Thinking of it again:  
Since the namespace for the PC classes is the same with that of the base classes/properties, why not including them directly within the base RDFS? (i.e. providing at the end a single rdfs file that also includes the PCs). 
Properties of properties are part of the official documentation (of the base model, or of an extension), so why not including the corresponding PC classes in the same RDFS file instead of providing and maintaining a second file? (this applies for both the base model and the extensions)

This is just a suggestion without knowing any discussions, or decisions made, when implementing the PC classes for the first time several years ago (there might be a good reason for having a second file...). 

Best regards,

Post by Martin Doerr (24 March 2022)

I think this is a good idea! 


Post by Philippe Michon (05-Apr-2022)

Dear all,

I strongly second this proposal. In my opinion, there is a serious lack of guidance as to how we are supposed to use .1 properties. In my opinion, the management of PCs should not only be considered in order to overcome a technological limit. I believe there is some interesting semantics within PCs that would be worth describing more formally.

If I'm not mistaken, .1s are only very briefly described in the CRMbase specification. I quickly found only five snippets (I didn't include the new proposals about .1 properties in 7.2.1):

In the "Terminology" section under "property": " Properties may themselves have properties that relate to other classes (This feature is used in this model only in order to describe dynamic subtyping of properties)."

in the "About the logical expressions used in the CIDOC CRM": "properties of properties, " .1 properties" are named by ternary predicate symbols; conventionally, we use P14.1 as the ternary predicate symbol corresponding to property P14.1 in the role of. "

in the "Extensions of CIDOC CRM": "Existing properties can be extended, either structurally as subproperties, or in some cases, dynamically, using properties of properties which allow subtyping (see section About Types below)."

in "Specific Modelling Constructs" under "About Types": "Analogous to the function of the P2 has type (is type of) property, some properties in the CIDOC CRM are associated with an additional property. These are numbered in the CIDOC CRM documentation with a '.1' extension. The range of these properties of properties always falls under E55 Type. The purpose of a property of a property is to provide an alternative mechanism to specialize its domain property through the use of property subtypes declared as instances of E55 Type. They do not appear in the property hierarchy list but are included as part of the property declarations and referred to in the class declarations. For example, P62.1 mode of depiction: E55 Type is associated with E24 Physical Man-made Thing. P62 depicts (is depicted by): E1 CRM Entity"

and in "CIDOC CRM Class Declarations": "Properties of properties are provided indented and in parentheses beneath their respective domain property."

My questions and comments:

I believe it would be particularly important to clarify if it is possible to use the .1 property of a superproperty with one of its subproperties. For example, is it allowed to use P3.1_has_note with P190_has_symbolic_content? According to my understanding this is not possible, but I do not believe it is explained anywhere. And if it is indeed possible, the PC extension does not allow this semantics.

Another issue is the fact that "PC0_Typed_CRM_Property" is not part of the CRMbase class hierarchy. I can understand the reasons behind this choice, but again these would need to be defined. In the context of our work at CHIN, we would sometimes have appreciated using a "P2_has_type" on a PC class in order to type it more formally. Is this something the SIG would encourage?

There is also an issue with P67_refers_to and P138_represents. The last is a subproperty of the first and both have a .1 property. In the PC extension, this hierarchy is completely lost, which limits the possibilities of inference. I don't know how to manage this according to CRMpc, but this problem should at least be documented if there is no concrete solution. I don't believe identifying PC138_represents as a subclass of PC67_refers_to would completely resolve this issue. Moreover, this representation would again raise the question concerning the inheritance of .1 properties by subproperties.

In the same vein, the question of the relationship that exists between the structure of PCs and their corresponding CRMbase properties is not explicit. If a user wants to implement P67_refers_to and PC67_refers_to in their knowledge graph, how should they implement the whole thing? Should the ontology support this kind of inference (in the RDF), or should it be handled at the query level?

I also believe that it would be important to standardize the names of the PC entities. For example, why are the first letters of "PC0_Typed_CRM_Property" capitalized while other classes are not (eg. PC3_has_note)?

Now that we formalize the .1 properties, I think it would be more than necessary to have an official scope note for each of them. The vast majority are only very poorly documented in the scope note of their respective property. It is also important to mention that "PC0_Typed_CRM_Property", "P01_has_domain", and "P02_has_range" don't have a scope note at all.

It is also difficult to easily find all the information about .1 properties. Would it be useful to have a dedicated section for them in the introduction?



Current Proposal: 

In the 53rd CIDOC CRM & 46th FRBRoo SIG meeting, PF walked the Sig through the current state of the issue -2 rdfs files generated per published CRMbase model (one for the ontology, one for the Property Classes); plus the following subtopics raised by PM:

  1. List the .1 properties of the CRM in the specification document

This particular point has been addressed (and resolved) by Issue 571: a list of all the .1 properties will be added in a tabular form under current table 4 (properties table). Links from that table to the .1 property definition in the document.

Proposal: add scope notes for .1 properties –not for v7.1.2 because there is no time before it is submitted to ISO but for v7.2.1 and on it is definitely something to consider

It is also relevant for Issue 556

  1. Proposal to merge the 2 rdfs files (ontology & pc module); apply this policy in extensions too

Objections to that on the grounds that

  • it is trivial to implement the .1 properties in a different file, whereas incorporating them to the ontology file would mean that they need to be used.
  • if one wants to extend the PC module for an application, they should not have to extend the core model as well
  • there are other ways to implement .1 properties, it doesn’t have to be through reification.

Decision: The relation between the CIDOC CRM and the PC module (rdfs implementation of the .1 properties) should be expressed in a comment in the CRMbase file) to minimize confusion

HW: PF to write the statement in the ontology file.

  1. Provide scope notes for all PC constructs (using ‘rdfs:comment’)

Proposal: since PCxxx is the same as Pxxx from the point of view of ontology, the scope note of PCxxx could consist of a statement along the lines of “this is the materialization of Pxxx to implement rdf reification. The property means (repeat the scope note of Pxxx)”

HW: PF to prepare a draft statement to be reviewed by the Sig

  1. Provide implementation guidelines (generate rdf triples using PCs; run SPARQL queries)

Two options available:

  1. Always use the property (e.g., ‘P14 carried out by’) together with its PC class  (‘PC14_carried_out_by’) E.g.:


:painting_sistine_chapel   a  crm:E7_Activity ; 

            crm:P14_carried_out_by :Buonaroti .

:Buonaroti   a  crm:E39_Actor . 

:instanceOfPC14   a   crm:PC14_carried_out_by ;          

            crm:P01_has_domain :painting_sistine_chapel ;                      

            crm:P02_has_range :Buonaroti  ;

            crm:P14.1_in_the_role_of  :master_craftsman . 


QUERY EXAMPLE: Requesting all activities, together with their actors and the role of each actor 

SELECT ?activity ?actor ?role WHERE {    

   ?activity a crm:E7_Activity ; 

           crm:P14_carried_out_by ?actor .    


       ?x  a crm:PC14_carried_out_by ; 

             crm:P01_has_domain ?activity ;          

             crm:P02_has_range  ?actor ;         

             crm:P14.1_in_the_role_of ?role } }


  1. Use the PC class without using the property


:painting_sistine_chapel a  crm:E7_Activity . 

            crm:P14_carried_out_by :Buonaroti .

:Buonaroti  a  crm:E39_Actor . 

:instanceOfPC14   a   crm:PC14_carried_out_by ;          

            crm:P01_has_domain :painting_sistine_chapel ;                      

            crm:P02_has_range :Buonaroti  ;

            crm:P14.1_in_the_role_of  :master_craftsman . 

QUERY EXAMPLE: Requesting all activities, together with their actors and the role of each actor 

SELECT ?activity ?actor ?role WHERE {      

       ?x  a crm:PC14_carried_out_by ; 

             crm:P01_has_domain ?activity ;          

             crm:P02_has_range  ?actor .       

       OPTIONAL {  

            ?x  crm:P14.1_in_the_role_of  ?role }  }

// the query makes no use of ‘crm:P14_carried_out_by’


  • (b) problematic, in the sense that neither the dataset nor the query make use of P14, so one cannot exploit sub/super property information, make reasoning, etc
  • (a) unmanageable, in the sense that it requires users to double the effort. It should fall on the users to query for both P01-PCxxx-P02 and Pxx.
  • Union SPARQL query (E39 Actor in the range of P14 displayed along with the E39 Actor in the range of P02 has range) as a 3rd scenario (to be included in the statement)
  • Given comments above: resolve this by drafting a recommendation document that lays out the two approaches –namely: if data generation process allows case (a) then go for it, if not, the recommendation is to use case (b) but query for both Pxxx and PCxxx. Also include 3rd scenario in the statement.

HW: PF detailed descriptions (and draft a query for case 3).

The other issues addressed in PMs response are to be discussed at a later stage.

Another point raised was the directionality of PC properties (forward going vs. inverse form).


May 2022

Post by Thanasis Velios (7 July 2022)

Dear all,

I am reading through the discussion on issue 588 ( and looking forward to Pavlos's HW.

I was thinking that we should connect in the graph the property with its reified class. E.g.:

crm:PC14_carried_out_by → crm:P0x_reifies → crm:P14_carried_out_by

This way the two are connected in the graph and some automatic querying could be possible to programme.

With the usual apologies if I have misunderstood the discussion.

All the best,


Post by Pavlos Fafalios (12 September 2022)

Dear all, 

Please find my homework for issue 588 in the below link (as well as in the issues' folder):


Apologies for the delay! Feel free to add your comments or send your feedback! 

Best regards,


Post by Mark Fichtner (12 September 2022)

Dear all,

nice work, thanks! I think for RDF this is a valid representation, although I am not very happy to add properties that are not in the cidoc crm directly and that are not part of the language itself (like in this case crm:P03_reifies). As a user/reader of the rdf it is simply hard to understand what is part of the cidoc crm itself and what comes due to "workarounds". Even in as a new ontology/file/addon it mixes cidoc crm and non-cidoc crm things. 

Also we have a reification concept (E13 Attribute Assignment), I am not sure if we need even more of these.

I'm looking forward to the discussion!


Mark Fichtner

Germanisches Nationalmuseum