No, Liddy. Not all activities that involve learning involve teaching.
For that matter, it's sadly true that not all activities that involve
teaching involve learning. But we're interested in all the activities
that involve learning.
Apart from that I agree with you that teaching is important, and the
educationally significant "thing" is the activity which is often
separate from the resource.
So learning activities OK; teaching resources, nope; and the difference
is not just one of political correctness.
Phil
Liddy Nevile wrote:
> yes. Sloppiness on my part.
>
> Your following points are right and make me think again that
>
> 1. we should be focusing on 'teaching' resources not 'learning'
> resources and
> 2. perhaps describing an activity linking in some resources but also
> talking about other characteristics of the teaching....
>
> With a description of the teaching as the central object of the
> description, you could still search for resources etc but they would
> be discovered as attributes of the teaching, but could also themselves
> have the usual sort of objective descriptions that we are used to.
>
> It seems to me this would not cause any problems for RDF thinking but
> traditional DC would not like it very much because the teaching would
> be an activity not an object.
>
> Liddy
>
>
>
>
>
> On 21/12/2009, at 10:04 PM, Andy Powell wrote:
>
>>> the accessibility example is very helpful because it is clear that
>>> describing the accessibility characteristics of a resource does not
>>> make it into any different kind of resource from what it was before....
>>>
>>> and I cannot see why describing the educational characteristics of a
>>> resource would actually make it any different kind of resource
>>
>> There is a difference (or so it seems to me). Accessibility
>> characteristics are inherent to the resource, educational
>> characteristics are not. Educational characteristics only come about
>> because someone decides to use a particular resource in a particular
>> way.
>>
>> Even a resource which is specifically designed to be a 'learning
>> resource' - a lesson plan for example - will have very different
>> educational characteristics depending on how it is used. Consider,
>> for example, a lesson plan used, as intended, by a teacher as part of
>> their K12 class. Then consider the same lesson plan used as a
>> case-study example in an undergraduate course as part of a degree in
>> teaching.
>>
>> The model therefore needs to include both 'Resource' and
>> 'EducationalUsage' and properties like 'difficulty' and
>> 'learningTime' have to be associated with the latter, not the
>> former. IMHO.
>>
>> Andy
>>
>> ________________________________
>>
>> Andy Powell
>> Research Programme Director
>> Eduserv
>>
>> [log in to unmask]
>> 01225 474319 / 07989 476710
>> www.eduserv.org.uk
>> efoundations.typepad.com
>> twitter.com/andypowe11
>>> -----Original Message-----
>>> From: DCMI Education Community [mailto:[log in to unmask]] On
>>> Behalf Of Liddy Nevile
>>> Sent: 18 December 2009 20:57
>>> To: [log in to unmask]
>>> Subject: Re: DC-Ed Application Profile: Defining resource classes for
>>> the AP
>>>
>>> I think there is a critical point here....
>>>
>>> the accessibility example is very helpful because it is clear that
>>> describing the accessibility characteristics of a resource does not
>>> make it into any different kind of resource from what it was before....
>>>
>>> and I cannot see why describing the educational characteristics of a
>>> resource would actually make it any different kind of resource -
>>>
>>> but I think that describing both the accessibility and the educational
>>> characteristics of any resource can be very useful to potential users
>>> of the resource. I don't understand why anybody would want to go
>>> further....I cannot 'get' the idea that resources have to be 'learning
>>> resources' to be useful to those teaching and learning while I
>>> recognise that some resources are very narrowly purposed to such use
>>> (a lesson plan, etc.).
>>>
>>> The history of DCEd work has been plagued by the problem of purpose as
>>> well as conflicting pedagogical theories and political correctness
>>> that somehow makes 'teaching' far less acceptable than 'learning'.
>>> Personally I have learned to live with the idea that everyone learns
>>> things all the time, usually over time not immediately when taught
>>> something but rather over time. I think it is better to think of
>>> teachers as teaching and so, when they are the audience of the
>>> metadata, to offer info about teaching with the resource for them, and
>>> when others are looking at the same resource, to offer info about what
>>> might be learned for them. And this means not worrying about
>>> constraining the (technical) domain but offering metadata that covers
>>> both kinds of info.
>>>
>>> Similarly with accessibility metadata, it can be used by someone
>>> looking for something and by someone avoiding something - the info
>>> available should be suitable for both uses.
>>>
>>> I think it is worth noting that a strong driver for the MLR Part 5 is
>>> being able to describe resources to facilitate their reuse, not just
>>> their discovery.
>>>
>>> Liddy
>>>
>>> On 19/12/2009, at 4:56 AM, Pete Johnston wrote:
>>>
>>>> Hi Stuart,
>>>>
>>>>> Pete, personally, I think you can be 100% sure.
>>>>
>>>> OK ;-)
>>>>
>>>> [snip]
>>>>
>>>>> These education properties share a kindred relationship to some
>>>>> rationally defined Learning Resource class as dcterms:accrualMethod,
>>>>> dcterms:accrualPeriodicity, dcterms:accrualPolicy bear to
>>> Collection.
>>>>> From that I concluded (rightly/wrongly?) is that an entity in our AP
>>>>> domain model to which such properties so declared 'belong' would be
>>>>> of
>>>>> the Learning Resource class.
>>>>>
>>>>> Pete, please correct me if my rationale of the _modeling
>>>>> consequences_
>>>>> of such an rdfs:domain declaration for these properties in the
>>>>> draft AP
>>>>> is right or wrong.
>>>>
>>>> I'm mostly thinking out loud here, rather than providing an answer
>>>> to your question, so apologies if this is way off target:
>>>>
>>>> I agree with you that the "cloud class" in the model diagram is not
>>>> the class of all resources (or the class of anything that can be
>>>> identified or anything that can be described), and it is rather some
>>>> subclass, the definition of which I'll happily defer to those of you
>>>> with the domain expertise, but which I'd be happy to call the class
>>>> of Learning Resources.
>>>>
>>>> I also think it's important to make a distinction between
>>>>
>>>> (a) The rdfs:domain of a property. This is a characteristic which is
>>>> grounded in the RDF semantics, so there are formal "entailment
>>>> rules" associated with it. It's also a "global" characteristic, and
>>>> doesn't change or "become restricted" if the property is referred to
>>>> in a DSP.
>>>>
>>>> (b) The "resource class constraint" used in a description template.
>>>> This is a purely structural constraint. It specifies the type(s) of
>>>> resources whose descriptions are to be subject to the constraints in
>>>> the template.
>>>>
>>>> So for example, many of the DCMI properties have no domain specified
>>>> i.e. their domain is the class of all things. But in a particular
>>>> DSP those properties might be referred to in statement templatesbut
>>>> within description templates which include particular resource class
>>>> constraints. And indeed within a single DSP the same property might
>>>> be referred to in statement templates within two different
>>>> description templates with different resource class constraints e.g.
>>>> in the SWAP case, there's a statement template for the property
>>>> dc:title in the description template for the FRBR Work class and for
>>>> the FRBR Expression class.
>>>>
>>>> Going back to the DC-Ed case, it seems to me part of the complexity
>>>> arises because the aim is to provide something which can be used in
>>>> multiple DSPs, but the nature of those DSPs is pretty much unknown.
>>>>
>>>> So I think there are possibly two scenarios:
>>>>
>>>> Approach (i): in that "host" DSP, "Learning Resource" is a "class of
>>>> interest", and the DSP contains a description template which
>>>> includes a resource class constraint for the Learning Resource
>>>> class, and within this description template, there are statement
>>>> templates referring to the "educational properties", as well as to
>>>> other properties
>>>>
>>>> Approach (ii): in that "host" DSP, "Learning Resource" is not itself
>>>> treated as a "class of interest", but rather there is another class
>>>> - like FRBR Expression or Document or Video or whatever - and a
>>>> description template which uses that class as a resource class
>>>> constraint, and within this description template, there are
>>>> statement templates referring to the "educational properties", as
>>>> well as to other properties
>>>>
>>>> And I'm not sure whether what is being proposed here is intended to
>>>> support:
>>>>
>>>> - only approach (i), in which case defining a class of Learning
>>>> Resource is essential; or
>>>> - only approach (ii) in which case defining a class of Learning
>>>> Resource (and having it as the domain of properties where
>>>> appropriate) may be helpful, because it provides additional
>>>> information to an application, but it isn't essential to
>>>> constructing the structural constraints - because the DSP will refer
>>>> to the class of Expressions or Documents or Videos or whatever; or
>>>> - both of the above, on a case by case basis
>>>>
>>>> And I did wonder whether differences of opinion about this point are
>>>> behind the differences of opinion about the need for the class?
>>>>
>>>> (At some point, I think Sarah made a comparison with the
>>>> accessibility case, where I think the intent is very much "approach
>>>> (ii)" but I'm less clear that that is the intent here)
>>>>
>>>> So I suppose I'm saying that, while it might be useful to have a
>>>> domain for those properties, maybe it's also worth trying to think
>>>> through how that "host" DSP might be constructed and what role a
>>>> "Learning Resource" class has in that process?
>>>>
>>>> Just thinking out loud...!
>>>>
>>>> Pete
--
Phil Barker Learning Technology Adviser
ICBL, School of Mathematical and Computer Sciences
Mountbatten Building, Heriot-Watt University,
Edinburgh, EH14 4AS
Tel: 0131 451 3278 Fax: 0131 451 3327
Web: http://www.icbl.hw.ac.uk/~philb/
--
Heriot-Watt University is a Scottish charity
registered under charity number SC000278.
|
