Re: [urn] gbs Name space identifier

[[e-mail] (Dale R. Worley)]

Certainly an interesing idea, but there are some things that need to be
clarified:

One thing you want to clarify is what sort of resources the URNs
specify.  From the way you write, I believe that they are intended to be
what are called BLOBs, finite sequences of octets, or files as a Unix
user thinks of them, with no metadata.  But that should be stated
explicitly.

>    <T> is a string of one or more characters drawn from: [a-zA-Z0-9_] which
>    identifies the type of content from a list of types published by the
>    registrant at https://metacpan.org/pod/Dita::GB::Standard::Types .

I attempted to obtain the list of valid types at the given URL, but was
unsuccessful.  That page seemed to be a very top-level discussion of
"The GB Standard".

>    <G> is a string of one or more characters: [a-zA-Z0-9_] chosen
>    algorithmically depending on the value of the <T> component. The possible
>    algorithms will be published on https://metacpan.org by the registrant. The
>    user is directed to the appropriate algorithm by a link published beside the
>    description of type <T> at:
>    https://metacpan.org/pod/Dita::GB::Standard::Types

As written, this provides no real constraint on the <G> value, other
than its character set, because there seems to be no constraint on the
algorithms involved.

I think the approach you want to take is to state that for each type <T>
there will be a published algorithm, and <G> has to conform to the
algorithm for <T>.

>    Identifier persistence considerations:
>
>        Persistence is guaranteed by the immutability over time of the MD5 sum
>        of the <B> component.

Because of <B>, there is a guarantee that if a URN refers to a resource
at a time, and at another time refers to a resource, then the two
resources are identical.  And that is the minimum needed for a URN
definition.

But there are no statements that types will not be removed from the list
of types, or that users might decide to use a different type for the
same resource, leaving two URNs referring to the same resource.
Similarly, what guarantees are there regarding the <G> algorithms over
time?

None of these questions are critical, but it would be much better if
you declared your intentions.

>     Equivalence is determined by comparing the <G> components of the two items
>     to be compared.  If they are equal the two items are considered to be equal.
>     Otherwise they are considered to be unequal even if the underlying content
>     is in fact identical.

If equivalence is determined solely by the <G> values, why are the <T>
and <B> values present in the URN?

>    The validity of the urn can be checked as follows:
>
>    Check that the <T> component is on the published list of possibilities.
>
>    Check that the <G> component is computed correctly when the algorithm named
>    by the <T> component is applied to the content.
>
>    Check the the <B> component matches the MD5 sum of the content.

That last item is ill-defined, as it requires one has the resource for
the URN, but there is no algorithm for constructing the resource from
the URN.

Dale