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

Hoyle, Larry larryhoyle at ku.edu
Sat Dec 18 15:07:38 EST 2010


Having the identifier (w/version)  unique  would seem to address the issue Alerk raises, where it seems like QuestionScheme is being used somewhat like a sub-Instrument.

For me this raises a more general issue about versioning of QuestionScheme itself. Suppose there are three questions in the scheme (QA, QB, and QC). In a second version of the scheme QA gets revised. What then if, in a different version, one wants to use the original QA and QC, but a revised QB? With the present kind of sequential versioning the third version of the scheme would have QA changed back to the original and QB changed to the new version.

What if there were a more explicit mechanism for inheritance in the scheme specification, e.g. something like an "InheritsFromVersion" attribute. This would also simplify specification of changes, and would allow in the example above both revised versions to point back directly to the original.  
 


Larry Hoyle
Senior Scientist
Institute for Policy & Social Research, University of Kansas
1541 Lilac Lane, Blake 607
Lawrence, KS  66045-3129

http://www.ipsr.ku.edu

-----Original Message-----
From: ddi-users-bounces at icpsr.umich.edu [mailto:ddi-users-bounces at icpsr.umich.edu] On Behalf Of Dan Smith
Sent: Friday, December 17, 2010 3:12 PM
To: Data Documentation Initiative Users Group
Subject: Re: [DDI-users] a question about schemes/versions/references

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



More information about the DDI-users mailing list