|
Hi all,
I belive that making technical.format optional would be the most useful -
* technical.format is/can be very useful (with uses well summarised by
Amber).
* Mandatory fields often lend themselves to junk data, as the users just
want the validator to stop complaining.
* People/groups who do use it can still make use of it, where it has been
filled in.
I'm pretty sure that automatic identification of mime types is a solved
problem [1].
This leaves identification of which files we need to generate this sort of
metadata (i.e. not 1px gifs), which I suspect will always be a human
editorial decision.
However, we can create a tool/tools to help the editor, perhaps along the
lines of:
1) Find/create your resource(s)
2) Point the tool at it, click "go"
3) The tool creates a list of files, parsing files it understands (e.g.
HTML) to find dependent resources (operating similarly to RELOAD, I
imagine).
4) The tool prepares a report with as much metadata as it can work out
filled in, for each of the files.
5) Review report for corrections and pruning of 1px gifs, etc.
6) (optional) create a list of resources not to generate metadata for (1px
gifs)
My 2p worth...
Cheers,
Dave.
[1] See the *nix `file` command
http://man.linuxquestions.org/index.php?query=file§ion=0&type=2
> -----Original Message-----
> From: Mark Power [mailto:[log in to unmask]]
> Sent: 05 March 2004 16:21
> To: [log in to unmask]
> Subject: Re: UK LOM Core - technical.format
>
>
> Far too simple to ever take off that I think Steve ;-) what
> would people
> be able to argue about then?
>
> Going back to what Duncan said about a user being able to search for
> pdf's or suchlike, using the technical.format element - I agree but
> surely it's only going to be really useful when you're
> dealing with an
> incredibly well populated repository....which I personally
> think we're
> quite a way off from.
>
> Steve, I like your idea but then of course I think 'well, you need to
> include copyright information' and of course as soon as you start to
> think something like that then the snowballing begins (educational
> context...)
>
> Back to the technical element for a minute though. If a
> learning object
> being imported into a repository consists of say, 3 webpages, a
> powerpoint presentation and a pdf then the creator will have to add
> metadata for each resource (including technical.format) yes?
> what goes
> in at top level, package level? And if a repository doesn't search
> through metadata included at such levels (organization,
> resource, asset
> [possibly] then it's pointless as you won't be able to find
> them anyway...
>
> Cheers
> Mark
>
> Steve Richardson wrote:
>
> > Hi Folks,
> >
> > This is a kind of side track, however, there is some
> relevance... so
> > here goes,, take it or leave it... just food for thought
> really... I
> > would appreciate any comments:
> >
> > How about a system that only requires three pieces of
> information for
> > it to become a searchable resource,,, title, description
> and url (Im
> > an advocate of the Dave Davies' school of RSS for
> Interoperability -
> > but see the benefits of more complete records i.e. LOM or whatever)
> > the rest of the metadata is optional but will be very easy
> to add in
> > at a later stage...
> >
> > Ill give a (simplified) example:
> >
> > Professor X finds resource... wants to share, but isn't a trained
> > cataloger
> >
> > So they simply add in title description and url... and the
> resource is
> > entered into the catalogue
> >
> > Cataloger Q comes along and sees a flag denoting an
> incomplete record
> > and adds in the extra information, (how is a different
> issue I wont go
> > into here, I have ideas for this) but is unsure on the MIME type
> > because they haven't had training in that area...
> >
> > MIME Magician M comes along and attributes the correct MIME type
> > resulting in a complete record...
> >
> > Some of this information could be added automatically as
> records are
> > harvested from one system to another...???
> >
> > Yes I know this will produce a system of (temporarily)
> incomplete LOM
> > records, but I don't see this as a problem... so long as there are
> > people who fulfill roles Q and M which there would have to
> be anyway..
> > right?
> >
> > any thoughts?
> >
> > Kind regards
> > Steve
> >
> > On 5 Mar 2004, at 15:27, Sarah Currier wrote:
> >
> >> Hi all
> >>
> >> Have to agree with Lorna on these points. I would also
> add- while I
> >> think it would be the best solution to find a way to add technical
> >> format automatically, where this isn't possible, I do
> think it should
> >> be well within the skillset of a trained metadata creator to cope
> >> with this (and drop-down menus would help). Metadata creation and
> >> management occupies a space on the boundary of technical and
> >> non-technical, and cataloguers of non-book materials (as we so
> >> quaintly used to call them) have always had to create conformant
> >> metadata about technical aspects of resources.
> >>
> >> Best
> >> Sarah
> >>
> >> Lorna Campbell wrote:
> >>
> >>>> 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,
> >>>
> >>>
> >>>
> >>> I agree, but the same could probably be said for 90% of the LOM!
> >>>
> >>>> 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,
> >>>
> >>>
> >>>
> >>> Not sure I would agree with you on that point.
> >>>
> >>>> or wrongly filled in.
> >>>
> >>>
> >>>
> >>> ... in which case it becomes a metadata quality control issue.
> >>>
> >>>>
> >>>> 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.
> >>>
> >>>
> >>>
> >>> This is unrealistic... an object that is "educationally
> relevant" in
> >>> one context may be quite irrelevant in another.
> >>>
> >>> My main concern with removing 4.1 from application
> profiles is that you
> >>> also remove a relatively popular search option from users.
> >>>
> >>> Bye
> >>> Lorna
> >>>
> >>>>
> >>>> 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/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> 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/
>>>
>>
>> --
>> *******************************************
>> Ms. Sarah Currier
>> Librarian, Stòr Cùram Project
>> "A Storehouse of Learning Resources for Social Care"
>> Dept. of Social Work, University of Strathclyde
>> c/o: 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
>> *******************************************
>
>
> .
>
|
