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

Wendy Thomas wlt at pop.umn.edu
Sun Dec 19 18:00:16 EST 2010


Thanks Sam,

Also good to get things restated in a way that is clearer.


Wendy

On Sun, 19 Dec 2010, Samuel Spencer wrote:

> 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
>>
>
> _______________________________________________
> DDI-users mailing list
> DDI-users at icpsr.umich.edu
> http://www.icpsr.umich.edu/mailman/listinfo/ddi-users
>

Wendy L. Thomas                          Phone: +1 612.624.4389
Data Access Core Director		 Fax:   +1 612.626.8375
Minnesota Population Center              Email: wlt at pop.umn.edu
University of Minnesota
50 Willey Hall
225 19th Avenue South
Minneapolis, MN 55455


More information about the DDI-users mailing list