Andy:
After long holiday hiatus, I wanted to thank you for your comments,and
respond by explaining a bit more specifically what the RLI WG is trying to
accomplish vis a vis the areas of confusion.
See my comments at ### below.
Nancy
On Thu, 18 Dec 2003 22:19:21 +0000, Andy Powell <[log in to unmask]>
wrote:
>On Thu, 18 Dec 2003, Nancy Hoebelheinrich wrote:
>
>> URN 1.1.1:General.Identifier.Entry 1.1.2:General.Catalog.Entry
would name
>> Location 4.2: Technical.Location Using either location (URL) or
method that
>> resolves to location (URI).
>
>Hi Nancy,
>I'm slightly confused by the way you are using the URN, URI and URL
>terminology here. You might find it useful to read
>
>http://www.w3.org/TR/uri-clarification/
>
>Consider the four following identifiers
>
>1) http://dx.doi.org/10.1000/203
>2) doi:10.1000/203
>3) urn:doi:10.1000/203
>4) info:doi:10.1000/203
>
>All the following statements are true:
>
>- All four are URIs.
>- 1) is a URL.
>- 3) is a URN.
>- 2) and 4) use URI schemes that are not currently registered (but they
> are still valid URIs).
>
>A URI is simply an identifier that conforms to the URI spec
>
>http://www.ietf.org/rfc/rfc2396.txt
>
>A URN is a URI that happens to start with the 'urn:' prefix.
>
>Therefore, I don't think that you really mean URN above - I suspect that
>you mean URI. I.e. an 'identifier'. In any case, there is no need to use
>1.1.2 ...catalogue to name the type of identifier (ISBN, ISSN, etc.)
>because all that information is contained in the URI (either as the URI
>scheme name, or as the URN namespace).
>
>Furthermore, your wording for 'Location' implies that a URL is always a
>location of something and that a URI can be resolved using some mechanism.
>Neither is true - URLs don't have to be the location of anything and URIs
>do not have to have a defined resolution mechanism.
>
>I suggest that what you need instead of the above is
>
>URI 1.1.1:General.Identifier.Entry 1.1.2:General.Identifier.Catalog
set to "URI"
>
>and
>
>Location 4.3: Technical.Location Use URL or OpenURL
### Regarding your comment #1: The purpose for putting in the element
name "URN" for the resources on a resource list was to provide specifically
for the inclusion of the ISBN or ISSN into a fairly traditional citation
format. The ISO standard we've been using (690-2) calls for what is termed
a "standard number" which has usually been the ISBN or ISSN, and the
examples that are included in the documentation specifically list the
number with the prefix of either ISBN or ISSN. See, for example:
(wordwrapped for convenience)
MYERS, Michael P.; YANG Jay; and STAMPE, Per. Visualization and functional
analysis of a maxi-K channel (mSlo) fused to green fluorescent protein
(GFP). EJB: Electronic Journal of Biotechnology [online]. 15 December
1999, vol. 2, no. 3 [cited 21 March 2000]. Available from:
<http://www.ejb.org/
content/vol2/issue3/full/3/index.html>. ISSN 0717-3458.
One could certainly argue that this is somewhat old fashioned, and indeed,
not necessary in the electronic environment, but I suspect faculty members
who want students to learn traditional citation formats may still want that
information included in the way described. At least, that's what we've
heard. So, what we were trying to do is both allow for that specification,
but also enable the use of the same information for the task of creating
the means of access to the resource itself as required by OpenURL and DOI.
Now, if as you suggest, we could use the LOM 1.1.1:General.Identifier.Entry
and the 1.1.2:General.Identifer.Catalog set to "URI", we would probably
need to specifiy in the Best Practices section of our Base Spec that the
ISBN and/or ISSN should be included explicitly when available for purposes
of stripping it out and including it into a citation format if / when it is
necessary or desirable to display the information in that way. It becomes,
in effect, an implementation issue. That might well work. I'd appreciate
any feedback from implementors on this list or from the RLI WG list.
Regarding your comment #2:
I said:
>
>> We're recommending that an OpenURL be created for each Resource or
>> Resource List if a persistent URL does not exist for either. All
>> components necessary to build an OpenURL are present in the
>> identification / description information above.
>
You said:
>This isn't quite true is it? The Volume designation, Part
>designation, Article Number, Starting & Ending Page Numbers, Total pages
>covered are not held in a structured format - therefore I can't
>generate an OpenURL based on your LOM record? That's why I suggest above
>that the OpenURL needs to be encoded in full using technical.location.
>
>This is what we are proposing for use within the RDN/LTSN LOM application
>profile in the UK. See...
>
>http://www.rdn.ac.uk/publications/rdn-ltsn/ap/
>
>Andy
>--
>Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
>http://www.ukoln.ac.uk/ukoln/staff/a.powell/ +44 1225 383933
>Resource Discovery Network http://www.rdn.ac.uk/
### Thanks for the reference to your application profile -- was very
interesting & helpful. In terms of the "Location" element, yes, this
requirement is especially confusing, I agree! Again, what we're trying to
do is provide a means for either popping in an already constructed URL, or
provide the means to construct one either via the OpenURL, DOI or PURL
standards. I think the language you use in the application profile
documentation is much more clear and specific for that element, so we may
well want to "borrow" that, if there's no objection.
In terms of the Volume designation and other information that we've
included in the LOM 7.2.2:Resource.Description element, it's true that
we've not specified the structure into which that information should be
entered because it is present for two, probably conflicting purposes. It
is, once again, important to include for display of one of a number of
accepted (traditional) article or other citation formats, but we also
wanted it to be available for building an OpenURL, thus requiring a much
more precise structure. The solution might be to still include both the
LOM Technical.Location element with values = URL or OpenURL, and the LOM
Resource.Description element. We could use Best Practices guidelines to
suggest that decisions need to be made upon implementation as to the most
practicable structure for entering the "components" of the
Resource.Description element should an implementor wish to build an OpenURL
from that metadata. Again, it would be useful to hear what implementors
think about the efficacy of this approach.
Thanks again for your comments and references, Andy.
Nancy
|
