Hi Chris

You seem to be living in a world where there is infinite resource for
metadata cataloguing and technical development.  I wish I lived in that
world too, but unfortunately I don't.

Chris Hubick wrote:

>Hi.
>
>I'm going to chime in on this from a technical perspective.
>
>I view Technical.Format as by far one of the most important LOM
>elements.  If a user finds metadata for a learning object, through a
>search or whatever means, and indicates they want to view that object,
>the system *MUST* know the Mime-Type in order to pass the data to some
>application for display.  There is a strong argument to be made that
>without knowing a Mime-Type, any learning object is *useless* - because
>the user/system won't know how to view it, or what to do with it, aside
>from saving a lump of binary data to your hard drive without even so
>much as a 3 letter extension.  My vote is that it should thus be a
>mandatory field, and catalogers should go to the end of the earth to
>find the type, or don't bother writing the metadata at all - or at least
>don't enter the mandatory field, and leave the metadata in a state that
>doesn't validate - an error which, technically, a machine can recognize
>and handle appropriately.
>
>
>
When importing a metadata record the first thing one must do, IMHO, is
validate it.  If it doesn't validate then, again IMHO, there is an
overwhelming argument to reject that record.  Are you suggesting that we
write event handlers to handle any error that parsing an invalid record
might create and make some 'intelligent' decision on what to do with it?

>Secondly - There is an fine yet important line between not knowing what
>something is, and not knowing how to display it.  By not leaving the
>Technical.Format field blank, and adding an 'application/unknown' entry,
>you will create confusion by moving from the first semantic to the
>second.
>
I may be wrong here, but my understanding of this debate is that the
application/unknown entry was a possible solution where a cataloguer
could not determine the type IFF this field was mandatory.  If it is not
mandatory then there is no need to add application/unknown, there simply
won't be an entry at all.  I am prepared to be corrected on this.

>Systems seeing this metadata will now see some entry, and thus
>*NOT* realize they don't really know it's type - and instead just think
>they need to find an application for displaying 'application/unknown'
>data - a decidedly different problem.
>
If I am correct with the above, then this problem will not occur.

>This is bad for interoperability,
>and will effect how sytems deal with the user when displaying your
>metadata.  The sytem may start looking through Mime-Type application
>directories for such a non-existant application.  I know our systems
>here try not to even make links to things we *know* will just give an
>error message back - ie, we won't put up a "View this Object" link if
>there is no Technical.Format, we will put up a nice message saying the
>type is unknown, which is better than some confusing browser error.
>Moreso, our system would probably not even want to harvest or accept a
>record with no Technical.Format, and this kludge will fool our sytem,
>which will lead to errors we don't expect, and are trying to avoid.
>
>Third, if an object is available in more than one type, as through
>content negotiation with a browser, I think this is exactly why
>Technical.Format is a repeatable element... why would you not make one
>Format entry for each type it is available in?  If anything else, I
>think you might consider writing a separate LOM for each format and
>LOM.Relation'ing them (hence the existance of the Relation.Kind
>'isformatof' vocabulary value).
>
>
>
LOM relationing them to what?  If you can't get at the underlying
XML/whatever, then you still have to make a decision on whether the
text/XHTML/pdf/SVG/whatever is the 'definitive object', that the others
are a format of.  You may be able to get a purl/POI/id/whatever for that
resource, but you still won't know what its underlying format is
(database/XML/whatever - v. Paul's comments on when does a resource
become a resource in a backend publishing pipeline?).

We could (arbitrarily) specify one of those formats as having priority
?? And I admit that the information may be useful in specifying the
different user agents, but there is a big resource issue here,
especially when cataloguing potentially transient resources.

>And if we are talking about writing metadata for a web page ('with many
>types')... I would think you should be writing a separate LOM for each
>image (or whatever) on the page, each with it's own Format entry, and
>using LOM.Relation's to associate them to a separate LOM for the HTML
>page itself (hence the existance of the 'ispartof' Relation.Kind).  (I
>asked Wayne Hodgins about exactly this yesterday when he was here, and
>he confirms this view).
>
>
>
Are you suggesting that I fire up my cataloguing interface to catalogue
all the 1-pixel gifs, banners, separators etc in a web page, and then
relate them ?  Phil mentioned a confusion here about  whether  we should
only catalogue 'educationally relevant' elements (subjective, and prone
to post-structuralist arguments), or catalogue everything.  If you are
suggesting cataloguing everything that the UK LOM core might
legitimately be applied to in this way, then you really must have near
infinite resource?

In the end, I think these debates come down to a tension between those
cataloguing web pages and the like, and those cataloguing RLOs in a
repository (as has been said before).  The UK LOM Core must serve both
(IMHO), and I would have thought  that anybody with repositiories of
RLOs ought to be specifying that *their* application profile makes this
field mandatory, which does not affect the desirability (ie Optional,
but recommended) of this field in the UK LOM Core.

Best

Nik

>My $0.06, Good Day.
>
>--
>Chris Hubick
>mailto:[log in to unmask]
>mailto:[log in to unmask]
>phone:1-780-421-2533 (work)
>phone:1-780-721-9932 (cell)
>http://www.hubick.com/
>
>On Tue, 2004-04-27 at 09:26, Paul Hollands wrote:
>
>
>>We also need a way to put an entry in even when the MIME type is
>>unknown. I have seen application/unknown used before in brower
>>configurations but I have a suspicion this a Microsoft kludge rather
>>than an acceptable MIME type. Do you think we should suggest putting
>>this into technical.format where it is unclear what the MIME type is and
>>the cataloguer doesn't have the resources to find out for certain?
>>
>>
>
>
>
>__
>    This communication is intended for the use of the recipient to whom it
>    is addressed, and may contain confidential, personal, and or privileged
>    information. Please contact us immediately if you are not the intended
>    recipient of this communication, and do not copy, distribute, or take
>    action relying on it. Any communications received in error, or
>    subsequent reply, should be deleted or destroyed.
>---
>
>