...

The model I'm imagining for EIs is that they are essentially blank nodes with permanent names.   They behave like blank nodes in RDF, i.e. kind of anonymous, they only have URIs  URIs to make it easier to tell which one of a parent instance's EIs is to be changed in an /update operation. There is the additional restriction that any given EI is only connected at ONE place in the graph, which is technically not a restriciton restriction of blank nodes but is often the case in practice.  &

Behavior

In general, EIs behave as if they are part of the parent. They are not subject to workflow and update actions by themselves, their contents may only be created or modified in the context of the parent.

*EIs do not have any of their own administrative or provenance metadata. This means ordinary users cannot modify an EI, subject it to workflow transitions, etc.

Creation

An EI is created by adding a new URI with an appropriate rdf:type statement to a modification (including creation) of its parent. The type must belong to the embedded class group.

Modification, Deletion

Any modification of an EI must be done as a modification of its parent. The EI's properties, including type, may be changed; it may be deleted. These changes are recorded as a modification of the parent.

The changes to the parent and its EIs may be driven by one HTTP request to the /update service, and will be performed in a single transaction.

Dissemination

A dissemination request on the parent instance will include all of the statements about its EIs. The EIs will be filtered of hidden properties (e.g. admin data and contact hiding) by the same rules as the parent, and returned in the same serialized RDF graph.

Dissemination requests on EIs are not supported. It is not recommended, the results are undefined. In the first implementation in 1.1MS5, this only affects the repository's HTML interactive dissemination page, which is deprecated now anyway.

Harvest

EIs are not included in a detail=identifier harvest result.

...

Incremental reports: Since EIs do not have provenance metadata, deletions of EIs are not reported individually.Only ; only the change to parent gets reported.

Data Migration

Even before the time of the 1.1MS5 release, several site repositories contain instances of types which belong to the Embedded Instance group and must change to the new behavior. The migration procedure updates the data already in the repository so it conforms to the new expectations. This is an essential step: Without migration, the repository will refuse to accept changes to some non-conforming instances.

Migration will be implemented as part of the repository upgrade procedure in the upgrade.sh script.   All external search indexes must be rebuilt after the migration.   Since metadata is deleted, the incremental harvest will not return useful results.

...