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

[Samuel Spencer]

Dan, Alerk,

The identity issues not withstanding, Wendy's solution is workable,
and probably the most logically sound.

Looking at QuestionScheme and its child QuestionSchemeReference we get
the following scenario.
I start with a question scheme with 3 questions:
1: qs v1.0.0
       qA v1.0.0
       qB v1.0.0
       qC v1.0.0

2: But I update one and want this:
qs v2.0.0
       qA v1.0.0
       qB v1.0.0
       qC v2.0.0

3: Using Wendy's solution, using QuestionSchemeReference we include qs v1 in v2.
qs v2.0.0
       qs v1.0.0
       qC v2.0.0

4: Which give us the resolved look (not using excludes) of:
qs v2.0.0
       qA v1.0.0
       qB v1.0.0
       qC v1.0.0
       qC v2.0.0

A resolution service should be able to look at part 3 and resolve the
references to get to qsv2.0.0:qCv2.0.0 in O(n) or better if the
registry of objects was implemented in an intelligent manner. This
stands for an object, regardless of how deep in schemes it the object
sits.
The identities are still relatively consistent as well, as under this
method qsv1.0.0:qAv1.0.0 & qsv2.0.0:qAv1.0.0 now point to the same
object, but take into account their immediate context as well. However
the issue of identity management as Dan brought up is still an issue,
but one I would gladly discuss in depth in a separate more appropriate
thread.

In all, I think under the current system the above solution is a
reasonable (ie. space efficient, logically consistent) solution to
Alerks problem,

Wendy:
Sorry if I basically repeated what you were saying, but I felt it
necessary to point to the schema how to implement what you were
suggesting

Regards,
Sam.

--- Specificity is the soul of all good communication ---
--- When the game is over, the king and the pawn go into the same box ---



On 17 December 2010 22:12, Dan Smith <dan at algenta.com> wrote:
> 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
> _______________________________________________
> DDI-users mailing list
> DDI-users at icpsr.umich.edu
> http://www.icpsr.umich.edu/mailman/listinfo/ddi-users
>