JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for CETIS-METADATA Archives


CETIS-METADATA Archives

CETIS-METADATA Archives


CETIS-METADATA@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

CETIS-METADATA Home

CETIS-METADATA Home

CETIS-METADATA  November 2003

CETIS-METADATA November 2003

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Format of LOM titles

From:

Boon Low <[log in to unmask]>

Reply-To:

Boon Low <[log in to unmask]>

Date:

Thu, 20 Nov 2003 10:00:05 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (304 lines)

Dear metadata lovers,

Encoding journal article information in LOM is subjective and dependent
on the use/application context of the metadata. There are many
feasibilities in doing so as discussed in this thread, and I really
would like to emphasise that there is no 'THE ONE' approach that suits
all application context, but one that is pragmatic. To share our
experience:

1. OpenURL in Location
We did implement this function with several location elements with
different OpenURL permutations (query syntax). This is a valid
approach, despite several issues. One is the URLs pointing to a
specific base url of a resolver. This approach also makes decoding
OpenURL a precondition for extracting the citation information (c.f.
vCard hence is valid). Both issues makes the metadata more platform
dependent (specific OpenURL syntax and link resolver). The url may not
be valid for other link resolver, targets that uses different OpenURL
snytax etc. If the URL is implemented (i.e. it resolved to the actual
resource location), it is fine, otherwise, the URL becomes just a proxy
string for encoding the citation information, a.k.a bending the
location field?

A source from the IMS RLI  also suggested that OpenURL and other
proprietary, standard type links (e.g. JSTOR SICI, IEEE) could be
inferred and constructed from the metadata itself, by the application
involved dynamically, in addition to using the transmitted hard coded
links. This gives flexibility for generating various query syntax
suitable for different targets and link resolvers.

Also some our links resolve to a webpage representing the full record +
several URLs related to use of the item (and location).  This use is
not in the strictest sense, resolving to the actual location of the
resource, but invoking an 'option representation' instead, not sure if
LOM location accomodates such use.

2. Relation
A journal article is part of a *specific* journal issue, and can be
described in the 'relaition/isPartOf'. Andy: you are right to point out
the /relation//description field is used for describing 'the other
learning object', i.e. the journal title (granularity debate elsewhere
please). But it is not wrong to have the citation in the description
field because we are referring to a specific journal issue here:
volume, issue, part, number details all give the information about the
journal title to which the article is related. Hence this is perfectly
valid. The tricky bit here is the page details which is related to the
article, but this information is still contained within the journal
title and hence can also be used to description the journal title: i.e.
'vol 1, part 2, p.3' give description *about the journal title* where
the article can be found. If you felt adding the page no. is bending
the rule a bit, than perhaps the page details can be encoded in
/general//title, description (CanCore method 1 and 2 in Lorna message -
below), or annotation fields. For us, this method is practical since
the description is parsed and used as it is without any more
manipulation. And I don't necessary purport this as a de-facto
approach, since it also has the dependency issue similar to OpenURL,
i.e. making the description specific to a particular reference system.

Lorna: I am interested in the CanCore method 3, but felt that, it may
be difficult to use two LOM records per article manifestation. Our
application provides discovery services to repurpose library records
for use in VLEs; each query can generate many (e.g. 50) articles
metadata from different journal sources in a go. This approach add both
complexities and runtime overheads - but I am interested in exploring
it and in particular, how this can be automated. I don't feel that this
approach will become a common practice for manual usage and if it is
devolved to users who prone to taking the use of journal article out of
context (in reading list, papers etc.) without having to worry too much
about (tagging) the related journal title itself. Making tagging of the
journal title a prerequisite to the use of an article metadata may
likely to become a barrier, and may be best served by the proliferation
of existing and easily linked 'journal title/have part' records (not
common even in library practice?), and tools to automate the process,
making it transparent to users.

Bye for now.

Boon
----------------------
Boon Low, Learning Technology Officer
Edinburgh University Library
http://homepages.ed.ac.uk/boon/


On Wednesday, November 19, 2003, at 03:29 PM, Lorna M. Campbell wrote:

> Are you library types having fun??! You're seriously distracting me
> from
> the rest of my work you know .... :-}
>
> Just to pick up on a couple of points....
>
> Paul's vision of world domination i.e. dissagregate LOM, delete bits
> already covered by Dublin Core and use RDF to mix an match has already
> bee suggested by dozens of frustrated LOM implementors world wide. I
> think even those involved in the development of the LOM agree that if
> they knew then what they know now they would not have developed such a
> monolithic spec. Hopefully modular will be the way to go in the future.
>
> Sarah's comment about LOM being a baby spec in comparison to
> MARC....next time someone complains about having to use LOM I'll quote
> you! (Btw Sarah, you are an incorrigible librarian! :-)
>
> Paul's query about serials and collection titles... CanCore suggest the
> following:
>
> --Series--
> "Examples of series include television shows comprising individual
> episodes, individually titled books or e-texts grouped under a common
> title, or individually named learning objects grouped together under a
> course title. There are several possible solutions to accommodating
> both
> series and individual titles, the first of which is recommended by
> CanCore:
>
> 1. Indicate the title of the individual component or series episode
> followed by the series title in parentheses within the title element,
> including the word "Series:" at the beginning. This should be simple to
> implement, and its syntax lends itself to automated data migration.
>
> 2. Include series or secondary title information in
> 1.5:General.Description. This suggestion does not preserve the
> important
> semantic distinction between title and description, and may present
> difficulties for automated data migration.
>
> 3. Use the relation element to point from a metadata record for the
> series as a whole to those that describe the individual series
> components. In the metadata record for the individual episode, text, or
> other learning object, enter its title but do not enter the series
> title. In the relation element in the same metadata record, reference
> the series using the  is part of  vocabulary item for 7.1:Kind.
> Finally,
> ensure that a separate metadata record for the series itself is
> created.
> In the relation element(s) for this record, use the  has part
> vocabulary item for 7.1:Kind and reference as many individual series
> items as apply. Note that the General and Relation "Identifier"
> elements
> are understood as referring to a learning object itself rather than its
> metadata record. Consequently, this method indicates a relationship
> between metadata instances only indirectly, and may consequently
> present
> data integrity problems in distributed systems."
>
> Now I'd better get on with the rest of my job...
>
> Bye
> Lorna
>
> Paul Hollands wrote:
>
>> Thanks Sarah for formulating my insane mumblings into a cogent
>> argument.
>> Even I understand what I was talkling about now :)
>>
>> I think the only bit that wouldn't really fit in relation is the page
>> reference.
>>
>> Sarah Currier wrote:
>>
>>> Hi Andy and Paul,
>>>
>>> I don't think this is part of a discussion about what is a LO at all,
>>> although I really like the rest of Paul's email! I think the problem
>>> comes out of the complexity we are used to describing in a library
>>> catalogue record according to AACR2 and MARC, and what can be done in
>>> the LOM, and thus, how do we make the LOM do what MARC can do, or do
>>> we do what Paul suggests and mix-and-match? While the LOM looks
>>> complex to non-cataloguers' eyes, if you've ever worked with the four
>>> volumes of LC guidelines for using MARC, it looks like a little baby
>>> spec, barely formed.
>>>
>>> Anyway, the distinction I THINK Andy is making I have laid out below,
>>> to be shot down if necessary:
>>>
>>> Andy Powell wrote:
>>>
>>>>> I would have thought that using the Relation element would be
>>>>> another
>>>>> way of doing this, but Andy's subsequent email made me think; does
>>>>> this
>>>>> element only allow for relations to other electronic learning
>>>>> objects,
>>>>> or to any resource, such as a journal?
>>>>>
>>>>>
>>>>
>>>> I guess that relation can be used to provide information about 'any
>>>> other
>>>> resource' (on the basis that for most things, there will be
>>>> somebody,
>>>> somewhere that considers it to be a 'learning object')!
>>>>
>>>> My point is that, if you are describing a journal article then the
>>>> journal
>>>> is a 'related resource' (and therefore, information about it could
>>>> go into
>>>> 'relation') but the citation for 'the article in the journal' is
>>>> information about the article - therefore it doesn't belong in
>>>> relation.
>>>>
>>> Took me a minute to get my head round this; now I think you are
>>> differentiating between, for the following fabulous article:
>>>
>>> All About the Correct use of Semi-Colons by Sarah Currier published
>>> in
>>> the July 1561 issue of the Fully Refereed Journal of Unbelievably
>>> Anal
>>> Cataloguing Discussions.
>>>
>>> The "Relation" thing would be:
>>> Title: All About the Correct use of Semi-Colons
>>> IsPartOf (I'm making this up, can't be bothered looking at the LOM):
>>> The Fully Refereed Journal of Unbelievably Anal Cataloguing
>>> Discussions
>>>
>>> The citation thing (which would go in the URL according to Andy)
>>> would be:
>>> Title: All About the Correct use of Semi-Colons
>>> Citation: Fully Refereed Journal of Unbelievably Anal Cataloguing
>>> Discussions (July 1561), pp. 23-346.
>>>
>>> Now, I'm not sure that the latter COULDN'T just go in the relation
>>> field, although I take Andy's point about the distinction. I guess
>>> the
>>> question is, what is the easiest and most useful way to do this for
>>> the sake of both end users looking at records, and for sharing,
>>> cross-searching and exposing of metadata records?
>>>
>>> As for series titles and collection titles: good point Paul.
>>> Repeatable alternate title would be an excellent element for the LOM.
>>>
>>> Phew, I don't often get to have fun like this in this job.
>>>
>>> ;-)
>>> Sarah
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>> If Andy's solution was used, how would the information about the
>>>>> journal
>>>>> be made easily accessible to the end user? Would the user interface
>>>>> have
>>>>> to take the journal details out of the OpenURL and present them as
>>>>> a
>>>>> journal citation?
>>>>>
>>>>>
>>>>
>>>> Yes. That's what computers are good at! ;-) The OPenURL is designed
>>>> to
>>>> be machine-parsable.
>>>>
>>>> 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/
>>>>
>>>>
>>>>
>>>
>>> --
>>> *******************************************
>>> Ms. Sarah Currier
>>> Coordinator / Research Fellow
>>> Educational Content Special Interest Group (EC-SIG)
>>> CETIS (Centre for Educational Technology Interoperability Standards)
>>> Rm. 2.08B, Centre for Academic Practice, University of Strathclyde
>>> Graham Hills Building, 50 George Street
>>> Glasgow G1 1QE, Scotland, United Kingdom
>>> Tel.: +44 (0)141 548 4573 Fax: +44 (0)141 553 2053
>>> E-mail: [log in to unmask] Mob.: +44 (0)7980 855 801
>>> Web (EC-SIG): http://www.cetis.ac.uk/educational-content/
>>> Web (Dept.): http://www.strath.ac.uk/Departments/CAP/
>>> *******************************************
>>>
>>
>> --
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Paul Hollands <[log in to unmask]>
>> LTSN-01 Information and Web Support Officer
>> University of Newcastle, 16/17 Framlington Place
>> Newcastle upon Tyne, NE2 4AB
>> 0191 222 5888
>> <http://www.ltsn-01.ac.uk/>
>>
>
> --
> Lorna M. Campbell
> Assistant Director
> Centre for Educational Technology Interoperability Standards (CETIS)
> Centre for Academic Practice, University of Strathclyde
> +44 (0)141 548 3072
> http://www.cetis.ac.uk/
>

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2024
March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
October 2022
August 2022
July 2022
May 2022
April 2022
March 2022
January 2022
November 2021
September 2021
May 2021
April 2021
February 2021
November 2020
September 2020
August 2020
July 2020
June 2020
March 2020
February 2020
September 2019
August 2019
July 2019
June 2019
April 2019
February 2019
December 2018
November 2018
September 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager