Re: temporary urn:predicates

On 13 July 2015 at 16:42, Urs Holzer <urs@andonyar.com> wrote:

> On Mon, Jul 13, 2015 at 03:51:11PM +0200, Melvin Carvalho wrote:
> > On 13 July 2015 at 15:42, Urs Holzer <urs@andonyar.com> wrote:
> >
> > > On Tue, Jun 30, 2015 at 04:59:29PM +0200, Melvin Carvalho wrote:
> > > > I was talking recently about barriers to producing semantic web data.
> > > >
> > > > Normally a predicate has to be
> > > >
> > > > - A URI
> > > > - Preferably an HTTP URI
> > > > - Preferably an existing URI
> > > >
> > > > This (Im told) can be a barrier for newcomers.  They have to find the
> > > right
> > > > name for a predicate, the right URI, and then see if it's already
> used.
> > > If
> > > > not create their own vocabulary.
> > > >
> > > > At this point some might give up.
> > > >
> > > > So I was wondering how it might be possible to create a temporary URI
> > > that
> > > > people could use as a place holder, so the software still works,
> until
> > > they
> > > > think of a better name.
> > > > [...]
> > >
> > > One can use a UUID URN as a namespace:
> http://tools.ietf.org/html/rfc4122
> > > For example <urn:uuid:19b75eab-77bd-46a7-a9c6-1ff0fd135a56#>
> > >
> >
> > Thanks, yes I use this.
> >
> >
> > >
> > > There is also a URN namespace for examples:
> > > http://tools.ietf.org/html/rfc6963
> > >
> > >
> > It seems to me that when a variable is "just a name" then urn: as a URI
> > being "just a name" seems a very good fit.
> >
> > I've had a look at some, but not all, of the sub namespaces within URN.
> It
> > seems hard to pick one over the other, and that the top level of urn: was
> > designed for exactly this use case, and therefore, could be the easiest
> > place to build consensus around ... I could be wrong!
>
> http://tools.ietf.org/html/rfc2141 indicates to me that a urn needs a
> namespaces identifier (and consequently contains at least two colons).
> The required Syntax is
>         <URN> ::= "urn:" <NID> ":" <NSS>
> So, I would not use <urn:>.
>

Ah, that's very interesting, thanks!  Does anyone know the history of that
design decision?

So let's say there's a good reason for every name to have a subname (I dont
think this can easily be argued).

What subname would you give it?

urn:urn:foo  -- seems a bit strage

urn:name:foo -- I think again you're getting redundancy implied in the urn

urn:uuid:foo -- seems wrong, maybe it could work tho ... for me a uuid is
something that is generally generated and unique, names are not unique

I think there's a fundamental difference in philosophy of the web and the
ietf in this regard.  The IETF like to maintain top down registries, the
semantic web is all about bottom up design without registries.  So that's
the area there may be some tension.  Remember also that the U in URN was
*supposed* to mean universal, as per the web axiom.  But the IETF renamed
it to *uniform* (another mistake imho).  So perhaps a good opportunity to
raise this point wrt RFC 2141, however maybe implementations are needed
first.

So while this is a very good point.  I do think that top level urns are a
perfect match for names that are simply names ie variables.  We are seeing
increasing use of this in the semantic web so it would be good to come to
consensus on a model.  I've been using urn: for a while now, and it's not
broken any code.  So will keep experimenting and hearing feedback, thanks
for the input!


>
> http://tools.ietf.org/html/rfc3406 reserves all URN namespaces beginning
> with X- for experimental purposes.
>
> Finally you could also coin your own URI scheme, for example <private:>,
> but see http://tools.ietf.org/html/rfc7595#section-3.8
>
> I would suggest <example:> if the data is not published before removing
> all <example:> with proper URIs. Otherwise, if it is used in a larger
> context and the temporary URIs are replaced gradually, I would use UUID
> URNs ensuring uniqueness. <example:> has the advantage that one can
> locate them with a simple search. A URN may always be legitimate, so it
> would become more difficult later on to find out which URIs still have
> to be replaced with proper ones.
>