/[volute]/trunk/projects/theory/snapdm/doc/On Identity.txt
ViewVC logotype

Contents of /trunk/projects/theory/snapdm/doc/On Identity.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 557 - (show annotations)
Wed May 28 09:14:38 2008 UTC (13 years ago) by gerard.lemson
File MIME type: text/plain
File size: 3677 byte(s)
small fixes
1 The issue of the identity of object types must be addressed.
2 ------------------------------------------------------------
3 In particular, object type instances (ie objects) in SimDb (and the VO in general)
4 can have representations in various different contexts: XML, RDB (both DDL and query),
5 code. We must be able to handle the fact that the identity of the same object
6 can be represented in different ways, while preserving knowledge about the
7 single underlying object. We must furthermore be able to allow references
8 to the object to be expressed in different ways, again depending on the context.
9
10 For example.
11 - when an XML doc is created containing a new object to be registered in a SimDB,
12 no "SimDB-identity" has been assigned yet.
13 Nevertheless the creator may need to have references from one object to another.
14 If these are in the same document, an ID/IDREF representation may be used.
15 If they are in different documents this does no longer hold.
16
17 - When stored in the database, we can not assume that the user supplied
18 ID does not already exist in the DB. In our (generated) reference implementation
19 we use JPA in the mode that primary keys are generated for each row.
20 Within the database these id-s are also used in foreign keys representing references.
21
22 - When we want to bridge different databases, we can not assume that database id-s
23 generated in one DB will work in another. We have to make the host part of
24 a globally unique "IVO-id". Our proposal for references from one XML doc to
25 an existing object follows this same prescription.
26
27 - Users can have their own unique identifiers assigned to resources and maybe
28 "sub-resources". These need to be preserved. Currently we only support this
29 as an explicit publisherDID attribute on Resource (the root element) and on
30 Snapshot (the results). The latter we have added because we want to be able
31 to communicate to SimDAP services using these user-supplied IDs.
32
33 At runtime we need to be able to resolve these different identifiers.
34 In our reference implementation we do this by storing from 1 up to 3 different
35 identifiers per row. The generated databaseId (a bigint/long).
36 An xsd:ID (if supplied by and for future reference for the registrar),
37 An ivo-id, if supplied by the registrar @@TODO need to decide on this,
38 can registrars define their own unique ivo-id, or do we generate these in the
39 SimDB? Could use a prescription like
40 <sim-db-host>/<utype of object>#<generated id>
41 eg:
42 http://simdb.g-vo.org/simdb/protocol/Simulator#123456789
43
44 Our reference implementation uses various life cycle events to resolve the
45 identifier appropriate in a given context.
46
47 References are to be resolved similarly.
48 Depending on context a user must be able to
49 use the appropriate identifier of the referenced object to represent the reference:
50 - for remote references, outside of current context, use "ivo-id".
51 - for local references, inside an XML doc, use xml-id (as an IDREF).
52 - for local references inside a simdb/TAP, for examples when querying using ADQL,
53 use the appropriate foreign key column (a bigint/long).
54
55
56
57
58 TODO
59 ----
60 1. We need to compare this approach to the one proposed in the STC standard,
61 which uses XLink and similar techniques.
62 2. Can we use and expand the IVO Identifier spec to identify rows in a unique manner?
63 3. Do we allow users to define their own unique ivo-id's, or are these generated by us.
64 4. Do we need publisherDID-s on all possible objects? In that case these can be
65 defined implicitly, on "MetadataObject", and do not need to be explicitly defined on
66 Resource and Snapshot. These can be minOccurs=0.
67 5. ...
68

msdemlei@ari.uni-heidelberg.de
ViewVC Help
Powered by ViewVC 1.1.26