Ferl uses these fields. In our experience people want to know what
format the resource either because
a) they can't use all formats
or
b) because they particularly want some formats (as Charles D suggests)
and
c) Sometimes people don't think they want to know about the format but
actually need warning if it's a .swf or an .mmp (mindmanagermap) etc
I think there's 2 sides to it - aiding resource discovery and supporting
the user in downloading
Resource Discovery
One issue for us is zips - if we specify that a file is a zipped file,
the field data doesn't tell the user what's actually in it. (We use zips
for large single files or for multiple related files).
Aiding the user in downloading
We use the field to ensure that at the point of download the fileformat
icon is displayed and appropriate guidance can be given
Automatic vs manual
We did have manual file format cataloguing and have recently moved to
automatic tagging to save time on the 90% of straightforward single
format resources (with the ability to override the automatic
classification).
Pragmatic implementation
We have a policy of flagging up exceptions in the plain English
description - we try to flag up when there are multiple files in a zip
or more unusual file types. Icons and classifications are most likely to
be missed by the users with the least web skills, so we need that extra
guidance anyway.
Bit rambling there, but hope that all makes sense!
Amber
Amber Thomas
Ferl Content Editor
Becta
Millburn Hill Road, Science Park, Coventry, CV4 7JJ
tel: 024 76 847167
email: [log in to unmask]
website: http://ferl.becta.org.uk/
E-learning and inspection: book now for the regional launch events of
Demonstrating Transformation. http://ferl.becta.org.uk/fpp6
-----Original Message-----
From: Charles Duncan [mailto:[log in to unmask]]
Sent: 05 March 2004 13:50
To: [log in to unmask]
Subject: Re: UK LOM Core - technical.format
I would also support 4.1 remaining mandatory but for a different reason.
A very useful capability of this field is that it enables people to
search for pdfs or powerpoint presentations or mpeg movies etc. If it is
optional this power is lost as I'm sure few people would bother to
populate an optional technical field.
Charles
Lorna Campbell wrote:
> Hi Andy,
>
> Thanks for your comments. It's probably worth reminding everyone at
> this stage that the UK LOM Core is supposed to be based on common
> practice so if the general consensus is that 4.1 should be optional
> rather than mandatory then I'm happy to go with that. So please let
me
> know what you think!!
>
> Personally I'm inclined to suggest that 4.1 should remain mandatory
for
> the reasons below, however I'm open to persuasion!
>
>> 4.1 technical.format is currently mandatory in the UK LOM Core.
>>
>> In the RDN/LTSN partnership work there has been some discussion about
>> the
>> benefits of using technical.format vs. the cost of getting
cataloguers
>> to
>> populate the field correctly.
>>
>> Most real-world resources (even Web pages) are made up of multiple
>> objects, each having a different MIME type - therefore populating
this
>> field correctly is likely to be difficult in practice. Note: it
might
>> be
>> possible to automatically populate this field -
>
>
> I would suggest that it would be preferable for this field to be
> populated automatically but I realise that this may not always be
> possible. If this field is to be populated manually, e.g. via a web
> form, I would suggest that cataloguers are presented with a drop down
> list of terms which are mapped to underlying mime types e.g HTML web
> page for text/html
>
>> but, if so, it's not clear
>> to me why one would want to automatically populate the field at the
>> time
>> the resource is catalogued, as opposed to at some later point
>> downstream,
>> e.g. when the metadata is indexed or when resource is accessed.
>
>
> This is a very interesting issue... at what point should this
> information be captured and at what point does the metadata instance
> have to be "complete", at input, storage, access or transmission, in
> order to "conform"? I'm inclined to think that to some extent this is
> a workflow issue. As a user I wouldn't care at what point this
> information is captured just as long as it's there when I go searching
> for images for a learning object I'm building.
>
>> Additionally, it is not clear what end-user functional requirement is
>> being met by populating the field.
>
>
> LOM states that "This data element shall be used to identify the
> software needed to access the learning object" in reality though this
> element can also be used to provide the user with invaluable
> information on what CanCore refer to as the "resource medium". This
is
> particularly useful given that 5.2 Educational. Learning Resource Type
> is so problematic. One of the common criticisms of 5.2 is that not
> only does the vocabulary mix up from and function, it is also
imprecise
> when it comes to recording form. For example 5.2 Learning Resource
> Type. Narrative Text could refer to an object that has the Technical
> format text/html (e.g. a transcript of the text of the Magna Carta) or
> image/jpeg (e.g. an image of the original Magna Carta document). It
> may be very useful for an end user to distinguish between these two
> quite distinct resources.
>
> Having said all that I'm willing to consider making 4.1 optional if
> other implementors agree with Andy.
>
> Bye
> Lorna
>
>> In practice, the more generalised information found in 4.6
>> technical.otherPlatformRequirements is likely to be more useful to
the
>> end-user when discovering/selecting a resource. (For example - "I
>> don't
>> care whether the Web page contains GIF or JPEG images - all I want to
>> know
>> is whether I need anything more than my Web browser to use the
>> resource").
>>
>> In maintaining/developing the RDN/LTSN LOM Application Profile I
would
>> like to consider making 4.1 technical.format optional - however, I
>> can't
>> currently do that and remain compliant with the UK LOM Core.
>>
>> On balance, I wonder if making 4.1 technical.format mandatory and 4.6
>> technical.otherPlatformRequirements optional is the right way round?
>> I'd
>> appreciate other people's views on this - but would ultimately like
to
>> suggest that technical.format is made optional in UK LOM Core.
>>
>> Comments?
>>
>> 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/
>> ECDL 2004, Bath, UK - 12-17 Sept 2004 - http://www.ecdl2004.org/
>>
>>
>
> --
> 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/
--
--------------------------------------------------------------
Intrallect Ltd [log in to unmask]
Braehead Business Park Tel: +44 (0)870 234 3933
Braehead Road Fax: +44 (0)1506 50 5117
Linlithgow, EH49 6EP, Scotland http://www.intrallect.com/
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
|