Document Strategy for Modelling "Real World" Objects

[no-reply]

#12 established a need to support descriptions of (& other metadata about?) "physical" or "real world" entities that are described in the repository.

We need a model that can support this. Specifically, these objects commonly:

• have different identifiers
• have different creation dates and creators
• have different rights information, and if so definitely should be clearly distinguishable
• one may choose to maintain the physical/digital object description after a corresponding digital/physical object is destroyed

We should take care to note other use cases for this distinction represented in the project requirements. We should also aim to limit the impact of this support on the model and on the UI/UX for base-level users.

[no-reply]

cf. #12 (comment)

So yes, you need some distinction, but to have to object model distinguish between the physical and digital could easily get out of hand in some Range 14 or FRBR (choose your plane of madness) kind of way.

[no-reply]

The proposed high level model offers the basic structure. A general proposal for the semantics of these relationships is outlined in #17 (comment).

There is likely more to hash out, on both points. Specifically:

• How do we determine the descriptive scope of repository objects?
  • Can we discourage this line of thinking: "we want to change the metadata so this text displays in this place, and since this is just a repository representation meant to serve search and display use cases, why not?"
  • When should an implementer resort to RWOs?
• What kind of guidance can we offer on multi-Class pcdm:Objects?
  • Are we in trouble if a pcdm:Object is also (e.g.) a bibo:Book, due to explicit type statement or property domain/range? Is this considered a non-problem; or does it merely put us off ontologies we consider overly restrictive anyhow?
• Are there other points of RWO -> repository object connection that are in-scope?
  • In HyBox, should RWOs only point to top-level pcdm:Objects? Any pcdm:Object? Any entity?
  • How can we limit the implementation/UI fallout to work that addresses real use cases?

[anarchivist]

cc @saverkamp (for outside hybox use cases)

[azaroth42]

I think there should be the potential to link Collection, Object and Part. The map as separate resource from Atlas, with equally rich descriptive metadata, is a convincing use case to me. Some thing like: SHOULD for collection and work, MAY for part?

The distinction between RWO and DO I /hope/ will make the multi-class question less of an issue. There's a bright separation between them, so there won't be a pcdm:Object that's also a foaf:Person. hashtag DDTT

[azaroth42]

Closed by notes/design_principles.md no?

[azaroth42]

Calling this issue closed. Though we do need a RWO properties model -- which seems basically like blessing dpla:SourceResource and its properties?