Hi Jon,
Thanks for providing some background to to this work and for clarifying
how we could potentially go about making formal comments. I'll
explore the possibility of submitting comments through BSI to back up
any Mikael is able to make via the Swedish national body and you make
as DCMI liaison.
All the best
Lorna
On 31 Jan 2006, at 06:45, Jon Mason wrote:
> hi,
>
> I couldn't agree more with the general tone of this discussion.
>
> Comments recently posted on this list relating to the proposed SC36
> MLR standard are just the kind of comments that are now needed to
> ensure SC36 delivers relevant standards & doesn't confuse the metadata
> community any more than it already is. Unfortunately, though, for such
> comments to be "properly heard" & addressed they need to be formally
> submitted through National Bodies (like BSI in the UK, or the
> equivalent in Sweden) or, as a secondary option, Liaison Organisations
> (eg., DCMI). However, it is probably important to note that the
> document circulated is only the first "committee draft" (CD) & is
> already being balloted -- commenting on it may be problematic unless
> it happens very quickly. The next SC36 is not until mid March but
> formal documents that impact work should have been submitted by
> January 27. There is probably some scope for late submission but I
> doubt they would accept anything later than a week or 10 days late (ie
> Feb 3-6).
>
> Despite the DC Abstract Model having been discussed in earlier SC36
> working group meetings I can report that there seems to strong support
> for the ISO 11179 approach.
>
> I also participate in SC36 -- both as part of the Australian
> delegation and as DCMI liaison -- so I can make sure these comments
> are addressed. But they do need to be formally submitted.
>
> cheers,
> Jon
>
> At 12:24 AM 31/01/2006, Lorna Campbell wrote:
>> Hi there,
>>
>> I was going to add this to my long list of things to read "later"
>> but after Andy and Mikael's comments I though I'd better have a quick
>> skim over it before I forget!
>>
>>>
>>> Well, I'm not certain the authors are actually subscribed to this
>>> list,
>>> but hey, let's comment anyway :-)
>> I don't know if the authors are on this list either (although Phil
>> will know) however this definitely seems like something we should be
>> commenting on through both formal and informal channels. Perhaps
>> Phil and I should discuss how we can input comments submitted via
>> this list to the relevant SC36 working group? we can alos collate
>> comments and forward the to Norm directly if he's not already on this
>> list.
>>
>> Andy and Mikael have already pointed out some fundamental problems
>> with this approach and I have to say that I fully agree with their
>> analysis. I don't understand how having elements that can be used in
>> two different ways is going top make metadata implementation less
>> rather than more complicated. I'm also very concerned about how this
>> draft relates to IEEE LTSC's LOMnext initiative and the Joint
>> IEEE/LTSC Taskforce, particularly given that the latter initiative
>> seems to have the potential to actually start to make some real
>> progress towards the kind of the interoperability goals that the
>> draft ISO standard purportedly sets out to address.
>>
>> All the best
>> Lorna
>>
>>>
>>> I've also given it a quick read, and from what I've seen so far, the
>>> direction the standard is taking is much more problematic than I had
>>> anticipated.
>>>
>>> Frankly, I am a bit surprised that no care at all has been taken to
>>> align the abstract model with that of Dublin Core or RDF. If
>>> anything,
>>> the model as it stands succeeds in the quite challenging task of
>>> making
>>> it *more* difficult to align with DC and RDF than LOM already was.
>>>
>>> As Andy notes:
>>>
>>>> To make matters worse, allowing the semantics of the top level
>>>> elements/containers to change depending on whether their child
>>>> 'elements' are populated or not seems to be a recipe for confusion
>>>> rather than for clarification and simplification.
>>> LOM, for all its problems, at least has a stable semantics for its
>>> elements. For those who have not read the document, the issue is
>>> that
>>> top-level elements/categories can be used in two ways:
>>>
>>> "
>>> 1. As containers for more specific sub-elements. [...]
>>> 2. As a data element that can be assigned a particular value that
>>> describes the learning resource. In this case, the definition of the
>>> element is taken directly from the first the first, “leaf” data
>>> element
>>> beneath it from the first element occurring after it that asks for
>>> a
>>> value.
>>> "
>>>
>>> So, for example, Description sometimes means "An account of the
>>> intellectual content of the resource" and sometimes "A name given
>>> to the
>>> resource. Typically, a name by which the resource is formally
>>> known.",
>>> depending on the existence of sub-elements.
>>>
>>> Clearly, this also goes squarely against even the premises of the
>>> CORES
>>> agreement, where "element" are "units of meaning". The Description
>>> element is completely useless in such a setting.
>>>
>>> I truly cannot see how this fluency in meaning can possibly increase
>>> semantic interoperability. In LOM, the whole notion of "categories",
>>> some of which double as repeatable elements, was already
>>> problematic.
>>> The approach taken in MLR makes matters so much worse.
>>>
>>> The observation that different elements have differing
>>> relationships to
>>> the actual resource is important, and also something that has been
>>> pointed out as a problem in LOM for several years. See, for example:
>>>
>>> http://kmr.nada.kth.se/papers/SemanticWeb/LOMRDFBinding-ARIADNE.pdf
>>>
>>> http://www.ukoln.ac.uk/metadata/dcmi/dc-elem-prop/
>>>
>>> If the MLR standard is to achieve its stated goal
>>>
>>> "In order to both achieve interoperability and consistency with
>>> IEEE
>>> LOM 1482.12.1 and other approaches, the ISO 11179 is used in this
>>> current MLR standard, allowing the description of a conceptual level
>>> independently of any particular representation."
>>>
>>> it needs to solve the problem of element semantics. Mentioning ISO
>>> 11179
>>> does not help much if the basic model has the same kind of issues
>>> as LOM
>>> has.
>>>
>>> The rationale document also notes that the MLR standard tries to be
>>> more
>>> useful for "flattened" metadata approaches. Two of the more
>>> important
>>> "flat" models, DC and RDF, are actually going to find the proposed
>>> solution to that issue to be more problematic than the original
>>> issue
>>> ever was.
>>>
>>> I assume this is based on a misunderstanding of what "flat" metadata
>>> standards are capable of. For example, the "flat" DC model can be
>>> used
>>> to represent the complete structure of LOM including the
>>> hierarchical
>>> relationships, as the work on the LOM RDF binding and within the
>>> joint
>>> DCMI/IEEE LTSC taskforce has shown. Actually, I fail to see how the
>>> proposed model is going to make it any easier to implement in a
>>> relational database system, which is a claim being made.
>>>
>>> "Such an approach is intended to support interoperability with
>>> existing
>>> Dublin Core and LOM metadata instances and systems."
>>>
>>> Unfortunately, this proposal does not bring that dream any closer to
>>> realization.
>>>
>>> Mikael
>>>
>>>
>>> --
>>> Plus ça change, plus c'est la même chose
>>>
>>
>> --
>> Lorna M. Campbell
>> Assistant Director, CETIS
>> University of Strathclyde
>> +44 (0)141 548 3072
>> http://www.cetis.ac.uk/
>>
>>
>>
>>
>>
>>
> ====================
> Jon Mason
> International e-Framework Editor
> http://www.e-framework.org/
>
>
--
Lorna M. Campbell
Assistant Director, CETIS
University of Strathclyde
+44 (0)141 548 3072
http://www.cetis.ac.uk/
|
