[DDI-SRG] Proposal for DDI URN resolution and new format of DDI URN's

Tue May 19 03:21:17 EDT 2009

This is right. I forgot that.

Then we probably need some separator in the version field. It is not a 
clean design as I mentioned before, because additional parsing is 
necessary. A nested version element would be perhaps better.

Do we really need unlimited versions, would say 4 levels not be enough? 
Then related attributes for each level can exist.

With an unlimited number of versions AND wildcards on each version level 
we'll run into problems regarding the URN resolution. An efficient 
processing seems to be tricky in any case not only when using DNS. 
Wildcards can be used in DNS on each level separated by dots. 4 levels 
can be realized this way.

Achim

Wendy Thomas wrote:
> Remember also that DDI allows an unlimited and most commonly a two layer 
> minor version. In fact DDI itself is using a three layer 
> major.minor_invalidating.minor_noninvalidating structure
> 
> sorry to be so picky :)
> 
> 
> On Mon, 18 May 2009, Joachim Wackerow wrote:
> 
>> Then major and minor version must be differentiated in the URN.
>>
>> urn:ddi_3_1:DataCollection.Methodology=icpsr.us.ddi:DataCol_1(2_0).METH_2(1_1) 
>>
>>
>> would be
>>
>> urn:ddi:icpsr.us.ddi:3_1:DataCollection.DataCol_1.2.0.Methodology.METH_2.1.1 
>>
>>
>> With a wildcard
>>
>> urn:ddi_3_1:DataCollection.Methodology=icpsr.us.ddi:DataCol_1(2_*).METH_2(1_1) 
>>
>>
>> would be
>>
>> urn:ddi:icpsr.us.ddi:3_1:DataCollection.DataCol_1.2..Methodology.METH_2.1.1 
>>
>>
>> The URN of the maintainable would be then:
>> urn:ddi:icpsr.us.ddi:3_1:DataCollection.DataCol_1.2
>>
>> The same as DNS name
>> *.2.DataCol_1.DataCollection.3_1.icpsr.us.ddi.urn.arpa
>>
>> Then the resolver (client) will get a list of responses, which must be 
>> sorted for the highest minor version number.
>>
>> It looks like an issue which should be further explored.
>>
>>
>>
>> The wildcard on the minor number is actually the late bound version of 
>> the minor number.
>>
>> Actually it would be much clearer when two fields in DDI would exist 
>> for major version and minor version. With the current way the content 
>> of version must be parsed (looking for the period) beyond of XML 
>> parsing. This is not a clear design.
>>
>> AbstractVersionableType has currently the attribute "version". It 
>> should have the attributes "majorVersion" and "minorVersion".
>>
>> BTW the XML Schema says that the separator between major and minor 
>> version is a period. The example URN's at various places in the 
>> overview and in the user guide use underscore.
>>
>> Anyway I would opt for the two attributes. Then we don't have to parse 
>> and we don't need the wildcard for getting the latest in minor version.
>> (already one regex less :) ). The documentation must be anyway fixed.
>>
>> The issue is strongly related to the discussion of the new URN format.
>>
>> Achim
>>
>> Achim
>>
>>
>> Wendy Thomas wrote:
>>> Much clearer. However, if there is not version number provided the 
>>> prescribed DDI is the default 1.0. How does this handle wildcards?
>>>
>>> Resolution of bug 198
>>> ACTION:
>>>
>>> Allow use of * for wildcarding version. Expand documentation to 
>>> explain this option
>>>
>>> Wendy
>>>
>>> On Mon, 18 May 2009, Joachim Wackerow wrote:
>>>
>>>> Wendy,
>>>>
>>>> Thanks for converting the format.
>>>>
>>>> Only the maintainable objects seem to be important for URN 
>>>> resolution purposes. See the assumptions in the introduction. So I 
>>>> focused just on these.
>>>>
>>>> urn:ddi_3_1:DataCollection.Methodology=icpsr.us.ddi:DataCol_1(2_0).METH_2(1_1) 
>>>>
>>>> would be
>>>>
>>>> urn:ddi:icpsr.us.ddi:3_1:DataCollection.DataCol_1.2_0.Methodology.METH_2.1_1 
>>>>
>>>> The structure of a full id of an object (maintainable object or the 
>>>> object itself) would be:
>>>> name-of-object.id-of-object.object-version-number
>>>>
>>>> When no version number exists an empty string between two dots 
>>>> represents this (not necessary at the right end).
>>>>
>>>> Each part of the URN can be understood as positional parameter in a 
>>>> strict hierarchy. It can be further discussed which separator 
>>>> characters would be optimal. A colon is anyway a separator in URN's. 
>>>> A dot is the hierarchical separator in DNS.
>>>>
>>>> The URN of the maintainable would be then:
>>>> urn:ddi:icpsr.us.ddi:3_1:DataCollection.DataCol_1.2_0
>>>>
>>>> The same as DNS name:
>>>> 2_0.DataCol_1.DataCollection.3_1.icpsr.us.ddi.urn.arpa
>>>>
>>>> The resolver (client) gets a URL or another URN as response, which 
>>>> identifies the DDI instance, where the maintainable object is 
>>>> contained. When the response is an URN, the resolver asks again the 
>>>> DNS for this URN and will get a URL, which identifies the DDI instance.
>>>>
>>>> Hope this clarifies, Achim
>>>>
>>>> Wendy Thomas wrote:
>>>>>
>>>>> Achim
>>>>>
>>>>> Upon readig this I am unclear regarding the object. Is this a 
>>>>> correct interpretation of the rewriting of the following urn 
>>>>> (current structure)
>>>>>
>>>>> urn:ddi_3_1:DataCollection.Methodology=icpsr.us.ddi: 
>>>>> DataCol_1(2_0).METH_2(1_1)
>>>>>
>>>>> Would now be:
>>>>>
>>>>> urn:ddi:icpsr.us.ddi:3_1:DataCollection.DataCol_1.Methodology.1_1.METH_2 
>>>>>
>>>>>
>>>>> What about version number of the DataCollection?
>>>>>
>>>>> Or do you mean:
>>>>>
>>>>> urn:ddi:icpsr.us.ddi:3_1:DataCollection.DataCol_1.METH_2.1_1
>>>>>
>>>>> So I don't ever declare what type of object I am referencing just 
>>>>> the type of its parent maintainable. Still have the question of the 
>>>>> version number of the parent maintainable. I can have two objects 
>>>>> in a maintainable with the same ID but different versions can't I?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, 18 May 2009, Joachim Wackerow wrote:
>>>>>
>>>>>> Arofan,
>>>>>>
>>>>>> We talked briefly about this issue at the last conference call. 
>>>>>> Here are more details.
>>>>>>
>>>>>> Achim
>>>>>>
>>>>>> -- 
>>>>>> GESIS - Leibniz Institute for the Social Sciences
>>>>>> Postal address: P.O. Box 122155, 68072 Mannheim, Germany
>>>>>> Visiting address: B2 1, 68159 Mannheim, Germany
>>>>>> Phone: +49 (0)621 1246 262
>>>>>> Fax: +49 (0)621 1246 100
>>>>>> E-mail: joachim.wackerow at gesis.org
>>>>>> www.gesis.org/en/institute/
>>>>>>
>>>>>
>>>>> 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
>>>>
>>>>
>>>> -- 
>>>> GESIS - Leibniz Institute for the Social Sciences
>>>> Postal address: P.O. Box 122155, 68072 Mannheim, Germany
>>>> Visiting address: B2 1, 68159 Mannheim, Germany
>>>> Phone: +49 (0)621 1246 262
>>>> Fax: +49 (0)621 1246 100
>>>> E-mail: joachim.wackerow at gesis.org
>>>> www.gesis.org/en/institute/
>>>>
>>>
>>> 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
>>
>>
>> -- 
>> GESIS - Leibniz Institute for the Social Sciences
>> Postal address: P.O. Box 122155, 68072 Mannheim, Germany
>> Visiting address: B2 1, 68159 Mannheim, Germany
>> Phone: +49 (0)621 1246 262
>> Fax: +49 (0)621 1246 100
>> E-mail: joachim.wackerow at gesis.org
>> www.gesis.org/en/institute/
>>
> 
> 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

-- 
GESIS - Leibniz Institute for the Social Sciences
Postal address: P.O. Box 122155, 68072 Mannheim, Germany
Visiting address: B2 1, 68159 Mannheim, Germany
Phone: +49 (0)621 1246 262
Fax: +49 (0)621 1246 100
E-mail: joachim.wackerow at gesis.org
www.gesis.org/en/institute/