[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