ok no one shoot me for doing this:

in section 9.1 Namespaces [Registry] of the OpenURL standard (z39.88) it
actually provides an example of using a URL in the rfr_id field, and i
wonder why you couldn't just do the same thing for the rft_id

also there is a field called rft_val which currently has no use.  this might
be a good one for it.

just my 2 cents.




On Mon, Sep 14, 2009 at 12:57 PM, Jonathan Rochkind <[log in to unmask]>wrote:

> Well, in the 'wild' I barely see any rft_id's at all, heh.   Aside from the
> obvious non-http URIs in rft_id, I'm not sure if I've seen http URIs that
> don't resolve to full text.  BUT -- you can do anything with an http URI
> that you can do with an info uri. There is no requirement or guarantee in
> any spec that an HTTP uri will resolve at all, let alone resolve to full
> text for the document cited in an OpenURL.
> The OpenURL spec says that rft_id is "An Identifier Descriptor
> unambiguously specifies the Entity by means of a Uniform Resource Identifier
> (URI)."  It doesn't say that it needs to resolve to full text.
>
> In my own OpenURL link-generating software, I _frequently_ put identifiers
> which are NOT open access URLs to full text in rft_id.  Because there's no
> other place to put them.  And I frequently use http URIs even for things
> that don't resolve to full text, because the conventional wisdom is to
> always use http for URIs, whether or not they resolve at all, and certainly
> no requirement that they resolve to something in particular like full text.
>
> Examples that I use myself when generating OpenURL rft_ids, of http URIs
> that do not resolve to full text include ones identifying bib records in my
> own catalog:
> http://catalog.library.jhu.edu/bib/NUM   [ Will resolve to my catalog
> record, but not to full text!]
>
> Or similarly, WorldCat http URIs.
>
> Or, an rft_id to unambigously identify something in terms of it's Google
> Books record:  http://books.google.com/books?id=tl8MAAAACAAJ
>
> Also, URIs to unambiguously specify a referent in terms of sudoc:
> http://purl.org/NET/sudoc/[sudoc] <http://purl.org/NET/sudoc/%5Bsudoc%5D>   => will, as the purl is presently set up by rsinger, resolve to a GPO
> catalog record, but there's no guarantee of online public full text.
>
> I'm pretty sure what I'm doing is perfectly appropriate based on the
> definition of rft_id, but it's definitely incompatible with a receiving link
> resolver assuming that all rft_id http URIs will resolve to full text for
> the rft cited.  I don't think it's appropriate to assume that just because a
> URI is http, that means it will resolve to full text -- it's merely an
> identifier that unambiguously specifies the referent, same as any other URI
> scheme.  Isn't that what the sem web folks are always insisting in the
> arguments about how it's okay to use http URIs for any type of identifier at
> all -- that http is just an identifier (at least in a context where all
> that's called for is a URI to identify), you can't assume that it resolves
> to anything in particular? (Although it's nice when it resolves to RDF
> saying more about the thing identified, it's certainly not expected that it
> will resolve to full text).
>
> Eric, out of curiosity, will your own link resolver software automatically
> take rft_id's and display them to the user as links?
>
> Jonathan
>
>
> Eric Hellman wrote:
>
>> Could you give us examples of http urls in rft_id that are like that?
>>  I've never seen such.
>>
>> On Sep 14, 2009, at 11:58 AM, Jonathan Rochkind wrote:
>>
>>
>>
>>> In general, identifiers in URI form are put in rft_id that are NOT  meant
>>> for providing to the user as a navigable URL.  So the  receiving software
>>> can't assume that whatever url is in rft_is  represents an actual access
>>> point (available to the user) for the  document.
>>>
>>>
>>>
>>
>> Eric Hellman
>> President, Gluejar, Inc.
>> 41 Watchung Plaza, #132
>> Montclair, NJ 07042
>> USA
>>
>> [log in to unmask]
>> http://go-to-hellman.blogspot.com/
>>
>>
>>
>