Skip to end of metadata
Go to start of metadata

P141's range should be "Property" not "CRM Entity"

Proposed CRM Change

A basic ResearchSpace need is to allow an art researcher to annotate pretty much any value of a cultural object.
E.g. the production person (called "attribution"), the production year, material, dimensions, etc.
E13 Attribute Assignment goes a long way to providing the annotation capabilities needed by ResearchSpace.

But there is an issue: while "P140 assigned attribute to" points precisely to the object under discussion,
"P141 assigned" lacks precision, and this is related to its range.

There are two problems:

  1. P141 cannot point to E59 Primitive Values, since they are outside the E1 CRM Entity hierarchy.
  2. If a value is shared between two properties (of the same or different object), the annotations of these properties become tangled.
    For example, assume a painting is made in Amsterdam and later sold in the same city. Consider these use cases, they cannot be expressed with P141 cleanly:
    • one researcher assigned the production place, and another the acquisition place
    • a researcher agrees with the production place, but disagrees with the acquisition place

Therefore I propose this change: P141's range should be "Property" not "CRM Entity".

Article

For details and illustrations, see: Vladimir Alexiev. Types and Annotations for CIDOC CRM Properties. Invited report in Proceedings of "Digital Presentation and Preservation of Cultural and Scientific Heritage" (DiPP2012) conference, September 2012, Veliko Tarnovo, Bulgaria. paper, presentation

  • In addition to annotations, it describes the need for property types (as opposed to sub-properties)
  • BM Association Mapping is based on the Reification approach described there

Implementation

The article proposes these alternatives for making statements "addressable", and we have to select one. Please provide your input!

I outline only the negatives (the article has more considerations but not all, and no conclusion yet).

  • Split Properties: eg P43F1 & P43F2 -> P43F
    • Cons: property-specific
    • Cons: property kinds and instances are multiplied 3x; more complex queries
      But Jana: doesn't affect basic display since P43F will be present in any case
  • RDF Reification
    • Cons: deprecated since 2005
    • Cons: property instances are multiplied 3.5x
    • Pro/Cons: generic solution, queries less intuitive
  • Named Graphs: use quads SPOG instead of triples SPO
    Barry, could you give link to OWLIM documentation on named graphs
    • Pro (Vlado): more economical representation
    • Cons (Vlado): more complex queries
    • Cons (Vlado): FTS indexing (molecule) cannot extend across G.
      But it's not a big loss since we probably want comments/author names to be indexed separately from the museum objects
    • Cons (Damian): not as efficient as S,P,O since OWLIM doesn't have primary indexes by G.
      Damian (OWLIM TL) advises not to use named graphs where the number of distinct G can be very large.
      (I need to get more details though)
    • Cons (Jana): keep in mind that some (or most?) third-party tools and libraries might not support them.
      For example, we are considering now RForms for GUI generation for RDF data and I have not seen anything about named graphs there.
      I don't know how standard named graphs are and how widespread their support is in the RDF world. If we are to utilize third-party tools, we are not to be too extravagant.
    • Vlado: named graphs are 6 years old (proposed 2005), standardized in SPARQL, and most repositories support them (which doesn't necessarily mean on par with normal triple components). So it's not some exotic stuff.
      If RForms will access the repo using SPARQL, we could remap quads into triples, eg using Reification vocabulary:

      or using domain-specific triples

    • Chat with Matthias Palmer, creator of RForms: changing RForms to work with named graphs won't be too hard

Lazy Statement Addressability

I assume most museum object properties will not be annotated, though we must provide in the UI the ability to annotate any leaf-level property.
So it will be smart to make statements (property instances) addressable "on demand" (lazily):

If statement <S,P,O> is not yet annotated, then there is only one (original) version for it

  1. Bind a button on the UI to this <S,P,O>
  2. If the user submits an annotation (comment, link, new value...) then:
  3. Generate a G
    • this can be an intermediate node (Alternative1), or a rdf:Statement node (Alternative2), or a named graph (Alternative3)
  4. Attach the annotation fields to G
  5. Amend the statement (depending the selected alternative: splice a node, or add G quad component)
    • overwrite the original statement

If statement is annotated (<S,P,O,G>)

  1. Bind the button to G
  2. If the user submits an annotation, bind it to G (and replyTo the previous comment)

Problems with this idea:

  • Damian: OWLIM does not maintain internal statement id's, so it cannot help with this. (But we can still generate it on demand and save it when needed)
  • Cannot have a statement permalink before the statement is annotated. So a researcher cannot post to another: "please comment here"
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.