Date: Fri, 29 Mar 2024 00:44:19 -0400 (EDT) Message-ID: <1233223206.872.1711687459445@prodopencatalystconfluence.catalyst> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_871_1034043020.1711687459442" ------=_Part_871_1034043020.1711687459442 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page describes how embedded instances are to be ma= naged by the repository. It does not say anything about other applica= tions.
The primary driver behind this design is the requirement by the data too= ls to have EIs edited with their parent in one atomic transaction.
The definition of an "instance" is effectively extended to cover its EIs= as well as its direct property values.
An embedded instance (EI) is = a resource instance which is hte value of an object property of an= other instance, its parent. What sets it ap= art from other instances which are object values are these conditions:
http://= eagle-i.org/ont/app/1.0/ClassGroup_embedded_class
The model I'm imagining for EIs is that they are essentially blank n=
odes with permanent names. They behave like blank nodes in RDF, i.e. k=
ind of anonymous, they only have URIs to make it easier to tell which one o=
f a parent instance's EIs is to be changed in an /update
opera=
tion. There is the additional restriction that any given EI is only connect=
ed at ONE place in the graph, which is technically not a restriction of bla=
nk nodes but is often the case in practice.&
In general, EIs behave as if they are part of the parent. They are not s= ubject to workflow and update actions by themselves, their contents may onl= y 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 trans= itions, etc.
An EI is created by adding a new URI with an appropriate rdf:type<=
/code> statement to a modification (including creation) of its parent. The =
type must belong to the embedded class group.
Any modification of an EI must be done as a mo= dification of its parent. The EI's properties, including t= ype, may be changed; it may be deleted. These changes are recorded as a mod= ification 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 tran=
saction.
A dissemination request on the parent instance will include all of the s= tatements 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 retur= ned 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 dep= recated now anyway.
EIs are not included in a detail=3Didentifier
harvest resul=
t.
When detail=3Dfull
, the graph of each EI (filtered accordin=
g to the same rules as the parent) is included in its parents description. =
The report can be expected to have the parent's statement whose object is t=
he EI appear before any statements in which the EI is the subject.
Incremental reports: Since EIs do not have provenance metadata, = deletions of EIs are not reported individually; only the change to= parent gets reported.
Even before the 1.1MS5 release, several site repositories contain instan= ces 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 e= ssential step: Without migration, the repository will refuse to accept chan= ges to some non-conforming instances.
Migration will be implemented as part of the repository upgrade procedur=
e in the upgrade.sh
script. All external search indexes must b=
e rebuilt after the migration. Since metadata is deleted, the incremental h=
arvest will not return useful results.
Here are the steps to implement migration of EIs and their parent instan= ces:
dcterms:modified
, claims, workflow, =
etc. Each EI will inherit the metadata of its parent. The continued presenc=
e of metadata would cause false results from incremental /harvest.
To find the orphans in your site repository, run this query against the = user-resources view:
select = distinct ?orphan where { ?orphan a ?eiType . ?eiType <http://eagle-i.org= /ont/app/1.0/inClassGroup> <http://eagle-i.org/ont/app/1.0/ClassGrou= p_embedded_class> graph :NG_Metadata {?orphan ?mdverb ?mdobj} optional { ?parent ?v ?orphan } filter(!BOUND(?parent))}