Hi Lorna, All
As part of the RDN/LTSN Interop group I was asked to produce a
discussion paper on this, which I did with my colleague Tom Hebbron:
http://www.prs-ltsn.ac.uk/technical/technical_format.html
As you will see we were interested in the possiblilites of assisting the
cataloguer through automation, and knocked together a *quick and dirty*
demo (works with images only), which you can find here:
http://prs-test.hebbron.com/MIMEtool.php
However, the issue that remains for us is that MIME types, however
carefully explained/mapped or whatever, are just something that the
non-technical cataloguer should not be exposed to IMHO, and at the end
of the day I would rather remove this from our cataloguring interface
altogether.
I fully take the points from you and Charles that this is useful
information, but it isn't useful if it is hard to capture, or wrongly
filled in.
If someone does have a reliable automatic tool, that can discern what is
educationally relevant from what is fluff, then I would love to hear
about it.
Nik
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/
|