Changes between Version 105 and Version 106 of BluePrintVITA

Timestamp:

11/29/10 13:47:47 (14 years ago)

Author:

Dominic König

Comment:

--

BluePrintVITA

@@ -91 +91 @@
 == Design ==
 
-=== Ontology ===
+
+=== Registries ===
+
+All data sets describing the same instance of a person entity form a '''file'''.
+
+All files for an entity type are accessible through a central '''registry'''.
+
+The registry implements the following:
+
+  - dereferencing of URI's
+  - CRUD access brokerage for file contents
+  - file-access auditing
+  - classification of files
+  - administration of file status
+  - administration of access permission to a file as a whole
+  - permanent removal of a file as a whole
+  - a directory of all available record types in a file
+  - coverage statistics of files
+  - export of a file as a whole
+  - import of a file as a whole
+  - merging of files
+
+=== Auditing ===
+
+VITA implementations must be able to log all successful attempts to access and/or manipulate data in a file, even if the application does not require auditing. All logs, regardless of their actual granularity, must be available as a function of the file.
+
+Data which will naturally change over time (e.g. the location of a person) must additionally be version-tracked in such way that they can be reconstructed for any point or interval of time.
+
+Data which only change upon administrative measures (e.g. names) do not need to be version-tracked.
+
+=== Data Model ===
+
+==== Overview ====
+
+[[Image(vita.png)]]
+
+This diagram is not complete and just meant to illustrate the general data structure.
+
+==== Background ====
 
 VITA defines four axes (aspects) for the construction of any "Personal Data":
@@ -106 +144 @@
   - [http://ontology.nursix.org/vita.owl OWL Source] ([http://ontology.nursix.org/vita.png Class Tree])
 
-==== Entity ====
+===== Entity =====
 
 The ''entity'' axis determines the entity type to which the data set relates (=ownership), which can be types of:
@@ -116 +154 @@
   - Relationship
 
-==== Distinction ====
+===== Distinction =====
 
 The ''distinction'' axis describes any features which are used to distinguish particular person entities.
@@ -126 +164 @@
 Identities don't have to be unique across multiple domains. In case they are not, any communications of identities have to enclose a reference to the domain which administrates the particular identity (administrative domain).
 
-==== Findings ====
+===== Findings =====
 
 ''Findings'' are all other features of the person entity which are to be communicated in this data set. These features can be assigned, observed or derived.
@@ -132 +170 @@
   ''In the VITA context, photographs or other images are findings, not evidence.''
 
-==== Evidence ====
+===== Evidence =====
 
 ''Evidence'' is any suitable means to describe the quality of data of the findings.
@@ -138 +176 @@
   ''This always includes at least information on origin and time of the particular finding, but can also include references and links to sources, or information on methods of determination.''
 
-==== Examples ====
+===== Examples =====
 
 {{{
@@ -174 +212 @@
   is a compliant set - it contains the "Entity" (pfif:person), "Distinction" (pfif:person_record_id, pfif:first_name, pfif:last_name), several "Findings" (pfif:sex, pfif:date_of_birth, pfif:age, pfif:photo_url) and plenty of "Evidence" (pfif:author_name, pfif:source_name, etc.).
 
-=== Registries ===
-
-All data sets describing the same instance of a person entity form a '''file'''.
-
-All files for an entity type are accessible through a central '''registry'''.
-
-The registry implements the following:
-
-  - dereferencing of URI's
-  - CRUD access brokerage for file contents
-  - file-access auditing
-  - classification of files
-  - administration of file status
-  - administration of access permission to a file as a whole
-  - permanent removal of a file as a whole
-  - a directory of all available record types in a file
-  - coverage statistics of files
-  - export of a file as a whole
-  - import of a file as a whole
-  - merging of files
-
-=== Auditing ===
-
-VITA implementations must be able to log all successful attempts to access and/or manipulate data in a file, even if the application does not require auditing. All logs, regardless of their actual granularity, must be available as a function of the file.
-
-Data which will naturally change over time (e.g. the location of a person) must additionally be version-tracked in such way that they can be reconstructed for any point or interval of time.
-
-Data which only change upon administrative measures (e.g. names) do not need to be version-tracked.
-
-=== Data Model ===
-
-==== Overview ====
-
-[[Image(vita.png)]]
-
 ==== Undefined values ====