[DDI-users] DDI-users Digest, Vol 63, Issue 3

[Pascal Heus]

All:
the other thing that concerns me here are the many "alternatives". This
is what makes DDI3 very difficult  if not impossible to process
generically as generic applications would need to be able to understand
all the possible variations. This is where I believe the DDI developer
community need to step in and come up with common/best practices (hope
this was discussed a bit at the developer meeting). I think different
flavors are unavoidable (we already have this the id/referencing
mechanisms) but having guidelines and documented use cases should help
keep this under control.
best
Pascal

On 12/18/10 12:00 PM, ddi-users-request at icpsr.umich.edu wrote:
> Send DDI-users mailing list submissions to
> 	ddi-users at icpsr.umich.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://www.icpsr.umich.edu/mailman/listinfo/ddi-users
> or, via email, send a message with subject or body 'help' to
> 	ddi-users-request at icpsr.umich.edu
>
> You can reach the person managing the list at
> 	ddi-users-owner at icpsr.umich.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of DDI-users digest..."
>
>
> Today's Topics:
>
>    1. Re: a question about schemes/versions/references (Dan Smith)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 17 Dec 2010 15:12:14 -0600
> From: Dan Smith <dan at algenta.com>
> Subject: Re: [DDI-users] a question about schemes/versions/references
> To: Data Documentation Initiative Users Group
> 	<ddi-users at icpsr.umich.edu>
> Message-ID: <4D0BD22E.1010903 at algenta.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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
>>
>