[gcs-pcs-list] on using URIs

[Mike Rylander]

On 3/1/06, Robert Sanderson <azaroth at liverpool.ac.uk> wrote:
>
> On Tue, 28 Feb 2006, Daniel Chudnov wrote:
> >The case for URIs includes:
>
> > - they refer to the same thing across applications
>
> Which is great, but not interesting for unapi surely where the use case
> is 'I want this that I see now' not 'I want the thing identified by X'
>
> > - they imply some measure of identifier persistence
>
> Which is a disadvantage because it means that dynamic content which is
> not persistent is less appropriate for unapi.  If the use case is 'I
> want what I see now' (copy), not 'I want to refer back to this in the
> future' (citation), then this means that we're adding hindrances.

Well, they don't have to though.  If Alf's blog posts use day granular
tag URIs, then the persistence is valid for that one day.  If my
catalog uses year granular tags then I should do my best to make sure
that the records are available for the entire year (or use a more
granular time specifier).  To put it another way, the time specifier
defines the "horizontal (temporal) persistence", the sub-URI at the
end defines the "vertical (cross-app) persistence", and as an added
bonus, the "authority identifier" can tell us where to go looking for
an unapi server

It seems like tags allow the structure of URIs, require (at least a
hint for finding) the original unAPI server, a time range for encoding
the "persistence" of URIs and the ability to use things like
"urn:isbn:...." at the end, for purposes that Dan is advocating (core
to the original unAPI idea or not) but without implying that the
identifier is valid elsewhere.

Before, I stated that I wouldn't try to push any particular scheme as
long as I can use whatever I like without breaking spec.  Now, I think
I will start pushing for tag URIs... :)

>
> > - where objects might be copied around using unAPI there is probably
> >   already some sort of implication of object+id persistence
>
> Why?
>
> >Fwiw, we're getting to the point where we should be weighing decisions
> >more and more w/r/to implemented code.  So, from the point of view of
> >the projects for which I'm using unAPI...
>
> Well, my code says that it's more complicated to put record identifier
> into a fake URI, and I think that Mike's code says the same thing.

I don't think my code says that.  I found it no more difficult to
create a fake info URI than to not, and I'd need to use a URI in any
case.  Our metarecords (interesting or not) will be unAPIed, and I'll
need to pass the type (record vs. metarecord) as well as the numeric
ID.

AFAICS, tag URIs aren't "fake" ... but I assume that's not your point.
 I think your point is that requiring URIs is "harder" than not, but
I'm not sure I buy that ...

  print "tag:$host:$year-$month:urn:$type:$id";

instead of

  print $id;


I'm all for URI, but I'm for it because they are easy to parse and
recognise.  I don't think they should imply any more utility, though,
than pointing to a resource that the accompanying <link> can help you
retrieve.

>
>
> > - it is easy to map specific identifier patterns to specific webapps
> > - without the standard URI prefix patterns, it might be impossible
> >   to efficiently assign a handler to a particular arbitrary identifier
>
> Isn't that a resolver, rather than a copy/paste format?
>
> > - having full URI patterns makes it easy to use a library like OPA
> >   to resolve ids
> Which is acting as a resolver, effectively.
>
> > - using full URIs makes it more likely that different pasted-in
> >   stuff can refer to the same thing consistently, e.g. if user1 writes
> >   about a book in a blog, user2 saves an amazon book link, and user3
> >   saves an OPAC record for the book, unalog can collate all three around
> >   the URI (as opposed to randomly differing variants on ISBNs)
>
> In the 'I want this thing I see' mode, this isn't important.  As soon as
> you get past that, then you're reinventing openURL.
>
> > - unalog itself referring to an object by its URI allows potentially
> >   better precision in service/content resolution, e.g. queries for
> >   object "12345" might return wildly different things with (unlike
> >   w/tagging) zero potential value to be derived from overlaps across
> >   disparate objects
>
> You even use the word resolution here.  I won't restate the obvious :)
>
> >Another good reason to require URIs is that bridging other protocols
> >(APP, OpenURL, OpenSearch/SRU) might be easier if implementers already
> >have fully-specified URIs.
>
> Ditto.
>
> >As for the Evergreen blog post:  Mike, I'd suggest that what you want
> >there isn't some tag or other made-up URI for your internal record
> >identifier, but rather the ISBN URI (e.g. urn:isbn:123456789X) relevant
> >for the item in your catalog (or an ISSN, etc.), unless an item in the
> >catalog has no known public identifier already.
>
> Not only is ISBN not consistently available, it's also not consistently
> unique.
>
> > - content identifiers represent publicly-known identifiers that are
> >   independent of system implementations.  all systems dealing with
> >   the same content item would use the same content identifier.  some
> >   examples would be ISBNs, PMIDs, flickr photo ids, blog post numbers,
> >   etc.  these are probably at least "precious" or "normal", to use
> >   Xiaoming's formulation.
>
> But you're dealing with one system.
>
> > - package and datastream identifiers represent specific-to-an-
> >   application identifiers that aren't necessarily public or known
> >   outside of the system itself.  maybe they are, maybe they aren't.
> >   some examples would be unalog entry ids, flickr image file URLs,
> >   repository bitstream uuids, etc.
>
> >imho unAPI is all about content identifiers.  Or, rather, you could use
> >the other kinds of identifiers with it, but if it really takes off as
> >an cross-application spec, it will be through the common use of content
> >identifiers, most of which can be usefully rendered as URIs.
>
> Then my claim (and Jeff's claim, I think) is that you're reinventing
> OpenURL.
>
> Rob
> _______________________________________________
> gcs-pcs-list mailing list
> gcs-pcs-list at cipolo.med.yale.edu
> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list
>


--
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org