[DDI-users] a question about schemes/versions/references

[Dan Smith]

Alerk,

I completely agree with you, I feel that the issue with the identity 
system in DDI 3 is currently the most pressing issue with the standard 
and its wider adoption. I have raised this same question several times 
which resulted in attempts to address it, but these fixes have only made 
implementation more complex without fixing or addressing the real 
underlying issue.

We -briefly- discussed your email on our last TIC call, and agreed to 
discuss it more in depth on our next call on Jan. 9th. It would be great 
if you could participate in this call since this issue is affecting your 
system's development.

Achim,

The first issue is there are 5 alternatives to finding an objects 
identity. This should be handled by the identity system and urn. Here 
are the issues with each of your proposed alternatives:

 > You can use different approaches to solve the issue:
 >
 > Alternative 1:
 > The QuestionItem for qA and qB can mention the objectSource, which is 
 >a reference to the object from which the item is being copied.

Alt. #1 requires a priori knowledge of content within the DDI model (the 
DDI's xml representation) in addition to the urn. This works fine when 
you have a complete XML DDIInstance already. In the case where a urn is 
being resolved, this information is not yet present.

 > Alternative 2:
 > qs v2.0.0 could reference qA and qB in qs v1.0.0 where they live.

Alt. #2 does not solve your issue of multiple urns, and has the same a 
priori problem as Alt. #1 in requiring knowledge of a "sourceContext" 
when resolving the urn. Including scheme items by reference also breaks 
down when including items from other schemes with the same versionable 
object id or a different agency identifier, as the new scheme's urns 
become either ambiguous or unreferencable without more context.

 > Alternative 3:
 > qA and qB could live in a resource package where they can be referenced
 > by wave 1 and 2.

Alt. #3 does not solve Alerk's issue since a question can not be 
contained in a resource package without a scheme, and the identity of a 
question is currently chained to a related scheme.

 >
 > Alternative 4:
 > It is possible to state in the comparison module that two questions
 > (here identical, but with different identifiers) are the same

Alt #4 does not solve the issue as there are still multiple urns, and 
again requires a priori knowledge. For this solution a users needs to 
know the identity of the comparison in addition to the urn you are 
trying to resolve. In addition, comparison is 1-to-1, so you would need 
n choose 2 instances of comparison to describe this equivalence. You 
would again need a complete DDIInstance with all the information, as the 
urn would not provide enough information for resolution.

 > Alternative 5:
 > With the grouping approach it is possible to push everything, which is a
 > candidate for reuse, to a higher level. Then no replication of objects
 > takes place.

Alt #5 again suffers the same problems as Alt. #4.


Wendy,

Your suggestion about using the sourceContext is Achim's alternative #2. 
This only works when presented with a DDI reference described in xml, 
part of the DDI model. The URN does not provide enough information to 
identify the object without additional information contained in the 
model. This creates ambiguous identities which is a problem for urn 
resolution because the current identity system expects a -specific- 
context through the use of the related parent maintainable.


All,
I agree that schemes are required, and that managing the context of a 
versionable item within a scheme is also a requirement. That said, the 
chaining of the identity of a versionable to its parent scheme is where 
the problem lies.

When this issue was last raised before the 3.1 release, a proposed 
solution was presented that allowed versionable items to have a unique 
id in accordance with ISO 11179. Wendy wrote up a great document 
describing how this would be accomplished based on a suggestion from Dan 
Gillman.

If a versionable did not have a unique id of its own, its parent 
maintainable's id should be concatenated to the versionable's id along 
with a non-id character between them, resulting in (parent|child) or 
(uniqueid). This change in creating a versionable object's id (ISO 11179 
data identifier portion of identity), requiring either a unique or 
concatenated identifier, would solve this issue in a clean and simple 
way, and be compatible with current DDI systems.

A DDI reference already allows for references to both an object and its 
context/scheme. With an object's id being unique, the context would be 
represented by the scheme reference. There would be no need for the 
sourceContext and objectSource workarounds. The URN format would remain 
unchanged, and allow for either referencing any object (maintainable, 
versionable, identifiable) directly -or- additionally including a 
specific maintainable to give context. This would also give a clear 
distinction between a reference to an object and a reference to an 
object in context, which is currently ambiguous in the urn.

I have posted Wendy's document here:
http://bit.ly/i8RBsD

I would appreciate anyone's feedback about this, cheers!
Dan


On 12/16/2010 5:44 AM, Alerk Amin wrote:
> Hello,
>
>     I have a question regarding schemes, versioning and references.  The
> following is a simplified version of a real use case that we have.
>
>     Suppose we have a QuestionScheme qs, which has 3 questions qA, qB,
> qC.  At the beginning (wave1 for example), we have
>
> qs v1.0.0
> 	qA v1.0.0
> 	qB v1.0.0
> 	qC v1.0.0
>
> At this point in time, its clear that any QuestionConstructs or
> Variables that reference these questions would use
> urn:ddi:agency:QuestionScheme.qs.1.0.0:QuestionItem.qA.1.0.0
>    or something similar (I might not have the exact syntax correct).
>
> Now, my question comes up when we move to wave 2.  Suppose qA and qB
> remain the same, but we change qC.  Now, we have
>
> qs v2.0.0
> 	qA v1.0.0
> 	qB v1.0.0
> 	qC v2.0.0
>
> Now, a reference to qA would be
> urn:ddi:agency:QuestionScheme.qs.2.0.0:QuestionItem.qA.1.0.0
>     Even though the question has not changed, we have a different version
> for the QuestionScheme, and therefore a different identifier for the
> QuestionItem.  If we have two different variables for the 2 different
> waves, they would have different QuestionItemReferences, and therefore
> it becomes impossible to determine that they are based on the same question.
>
>     Is my understanding of this correct?  If so, doesn't this hurt the
> reusability of items?
>     Thank you for your help.
>
> Best,
> Alerk
>


-- 
Dan Smith
+1 608-213-2867
Algenta Technologies, LLC
http://www.algenta.com