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

Joachim Wackerow joachim.wackerow at gesis.org
Mon May 18 11:42:06 EDT 2009


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/


More information about the DDI-SRG mailing list