Follow-up issues from the Oct 19th LRMI TWG call

[Greg Grossmeier]

Hello,

Below are the three major issues that came up during the LRMI TWG call on
October 19th.

For the current draft of the LRMI terms, as always, please see:
http://wiki.creativecommons.org/LRMI/Properties

If I failed to include any points made that are important, please do
reply with that information.

The goal is to come to a conclusion on one of the proposals below (or
another one I failed to provide) soon.

Best,

Greg

Genre/MediaType/LearningResourceType
====================================

It was brought up during the call that these three fields (or at least
two of them) are redundant and/or confusing.

First, here are the current definitions:

* mediaType: This is currently undefined in our spec, but based on
dc:type, dc:type= "The nature or genre of the resource." For the
vocabulary see: http://dublincore.org/documents/dcmi-type-vocabulary/

* learningResourceType: "The predominate type or kind characterizing the
learning resource." This was pulled from LOM.

* genre: "Genre of the creative work" This is the language from
Schema.org Based on the fact that this term is singular, Schema.org is
expecting only one genre per item. See the "Note on naming conventions"
here: http://schema.org/docs/extension.html

Proposals
---------

1) Get rid of mediaType and learningResourceType and only use genre as
the place to put such information as "handout" or "presentation."

* Pro: It reduces the complexity of the schema and it is less likely
that the person doing the data-entry will be confused about which
information to put where.

* Con: You will (potentially) lose some information, for example, in the
case where the (popularly thought of definition of) genre of a work and
its learningResourceType are different. Additionally, the definition of
genre may need to be modified to inform the person doing data entry that
this is the place to put such information like "handout" or
"presentation."

2) Keep learningResourceType but remove mediaType.

* Pro: Keep valuable semantic information and the ability to
simultaneously tag an item with both a genre and a learningResourceType.

* Con: Increases the complexity and potentially confusion for the person
doing the data entry.

Audience/intendedEndUserRole
============================

This issue deals with the fact that the term intendedEndUserRole is
confusing versus the more simple form of audience.

Proposals
---------

1) Switch the term from intendedEndUserRole to audience.

* Pro: This may make this term clearer for the individual(s) doing
data-entry. They won't have to think hard about a complex phrase such as
"Intended End User."

* Con: There may be some lost specificity.

Competency Terms
================

This issue revolves around the competency-related terms
(requiresCompetencies, teachesCompetencies, and assessesCompetencies).
Essentially, the question is: are these three terms overly
complex/nuanced? Is there a need to have all 3? Or, can we simply
condense them down to 1 or 2 terms (either addressesCompetencies or
teachesCompetencies and assessesCompetencies) with the thinking that
requiresCompetencies is too little used in this context.

Proposals
---------

1) Condense down the competency-related terms to just
addressesCompetencies.

* Pro: Vastly simplifies the space.

* Con: We lose a fair amount of information that is being collected. Not
as useful for other services.

2) Remove the requiresCompetencies term (just leaving teaches- and
assesses-).

* Pro: Removes a term that will potentially be
under/incompletely-utilized.

* Con: We lose a currently in-use term in some situations.

--
Greg Grossmeier
Education Technology & Policy Coordinator
twitter: @g_gerg / identi.ca: @greg / skype: greg.grossmeier

[Stuart Sutton]

On Thu, Oct 20, 2011 at 3:05 PM, Greg Grossmeier <gr...@creativecommons.org> wrote:

If I failed to include any points made that are important, please do
reply with that information.

Greg, there is one point discussed that is not reflected here--whether there is a schema.org equivalent for "Title" (first row in the LRMI General Terms table at http://wiki.creativecommons.org/LRMI/Properties).  The schema.org "name" property of Thing is defined as "The name of the item" and that seems (at least to me) to be semantically on target--since a title _is_ a kind of name.   The schema.org intention that "name" be considered coextensive with "title" seems like a reasonable inference since even thing/creativeWork/book relies on name.  You don't get any closer to the core concept of the name of something being its title than you do with a book. 

Stuart

--
Stuart A. Sutton,
CEO and Managing Director, Dublin Core Metadata Initiative
Associate Professor Emeritus, The Information School
University of Washington

[Greg Grossmeier]

<quote name="Stuart Sutton" date="2011-10-20" time="15:49:26 -0700">

> Greg, there is one point discussed that is not reflected here--whether there
> is a schema.org equivalent for "Title" (first row in the LRMI General Terms
> table at http://wiki.creativecommons.org/LRMI/Properties). The
> schema.org"name" property of Thing is defined as "The name of the
> item" and that seems (at least to me) to be semantically on
> target--since a title _is_ a kind of name. The schema.org intention
> that "name" be considered coextensive with "title" seems like a
> reasonable inference since even thing/creativeWork/book relies on name.
> You don't get any closer to the core concept of the name of something
> being its title than you do with a book.

Ah yes, thank you, Stuart. I did forget that one.

The terms have been updated.

http://wiki.creativecommons.org/index.php?title=LRMI/Properties&diff=prev&oldid=53381

Best,

Greg

[Stuart Sutton]

On Thu, Oct 20, 2011 at 3:05 PM, Greg Grossmeier <gr...@creativecommons.org> wrote:

If I failed to include any points made that are important, please do
reply with that information.

Greg, knowing what others consider "important" isn't always easy.  There was some discussion on the call (inconclusive, I think) as to whether the work product of the LRMI is _explicitly_ intended as a more "specific type" of schema.org CreativeWork--i.e., Thing/CreativeWork/LearningResource.  It seems important that we are explicit about whether this is the case so we can better frame intentions with the current General Properties table at [1].   Are we to infer from our table that we are actually proposing "extensions" to schema.org properties as framed by schema.org at [2]?  From our table, this would result in the following "extensions":

-- Thing:name/title
-- CreativeWork:about/subject
-- CreativeWork:dateCreated/date
-- CreativeWork:author/creator
-- CreativeWork:inLanguage/language
-- CreativeWork:genre/mediaType

If LearningResource is deemed by us to be a more specific type of CreativeWork, then we are building on the existing schema.org types/properties and should add new properties only as required by the specificity of a Learning Resource--i.e., we should only add LRMI properties that: (1) distinguish a LearningResource from other types of CreativeWorks; and (2) support Learning Resource characteristics important to search and a user decision to retrieve.  IMHO, we should not  create "extensions" to existing schema.org properties without a very clear showing that doing so buys us more in terms of necessary meaning than we lose in general understanding.  I don't see such a "very clear showing" with any of the six extensions noted above from our General Properties table and would focus LRMI efforts instead on paring down the number of properties in the Education Specific Terms to the level of specificity we see in the other more specific types of CreativeWork.

Stuart
 
[1]  http://wiki.creativecommons.org/LRMI/Properties
[2]  http://schema.org/docs/extension.html

[John Fontaine]

It seems like LearningResource should be thought of as an abstract
interface instead of as a direct subclass or extension of a particular
entity. That way the broadest set of objects could take these
attributes.

For example

<div itemscope itemtype="http://www.schema.org/CreativeWork">
....various creativwork attributes...

<div itemprop="LearningResource" itemscope itemtype="http://
www.schema.org/LearningResource">
...Vocabulary Specific items such as Educational Standards,
Competencies, Subject matter, Outcomes, etc....
</div>
</div>

One could add this LearningResource interface any Thing, or even
expanding beyond thing to Events and people. For example you have an
html page which contains a lecture series with a set of attached media
objects. The overall creative work might implement the
LearningResource interface with a broad definition, while each
embedded MediaObject might also have specifics related to each
specific lecture video's purported educational content.


John Fontaine

On Oct 22, 1:40 pm, Stuart Sutton <stuartasut...@gmail.com> wrote:
> On Thu, Oct 20, 2011 at 3:05 PM, Greg Grossmeier

> <g...@creativecommons.org>wrote:

>
>
>
> > If I failed to include any points made that are important, please do
> > reply with that information.
>
> Greg, knowing what others consider "important" isn't always easy.  There was
> some discussion on the call (inconclusive, I think) as to whether the work
> product of the LRMI is _explicitly_ intended as a more "specific type" of
> schema.org CreativeWork--i.e., Thing/CreativeWork/LearningResource.  It
> seems important that we are explicit about whether this is the case so we
> can better frame intentions with the current General Properties table at
> [1].   Are we to infer from our table that we are actually proposing
> "extensions" to schema.org properties as framed by schema.org at [2]?  From
> our table, this would result in the following "extensions":
>
> -- Thing:name/title
> -- CreativeWork:about/subject
> -- CreativeWork:dateCreated/date
> -- CreativeWork:author/creator
> -- CreativeWork:inLanguage/language
> -- CreativeWork:genre/mediaType
>
> If LearningResource is deemed by us to be a more specific type of
> CreativeWork, then we are building on the existing

> schema.orgtypes/properties and should add new properties only as

> required by the
> specificity of a Learning Resource--i.e., we should only add LRMI properties
> that: (1) distinguish a LearningResource from other types of CreativeWorks;
> and (2) support Learning Resource characteristics important to search and a
> user decision to retrieve.  IMHO, we should not  create "extensions" to
> existing schema.org properties without a very clear showing that doing so
> buys us more in terms of necessary meaning than we lose in general
> understanding.  I don't see such a "very clear showing" with any of the six
> extensions noted above from our General Properties table and would focus
> LRMI efforts instead on paring down the number of properties in the
> Education Specific Terms to the level of specificity we see in the other
> more specific types of CreativeWork.
>
> Stuart
>
> [1]  http://wiki.creativecommons.org/LRMI/Properties
> [2]  http://schema.org/docs/extension.html

> <http://schema.org/docs/extension.html%20>

[Joshua Marks]

John

I Agree, and I think this is a very defensible argument. A Learning Resource
can be anything (e.g. event, artifact, place etc.), and is not just a genre
of a creative work.

Joshua Marks
CTO
Curriki: The Global Education and Learning Community
jma...@curriki.org
www.curriki.org
US 831-685-3511

I welcome you to become a member of the Curriki community, to follow us
on Twitter and to say hello on our blog, Facebook and LinkedIn communities.

[Stuart Sutton]

Joshua & John, thanks, very useful comments.  I have to admit, though, I don't see the functional benefit in shifting the characterization from the schema.org modeling's "more specific type" to "abstract interface".  But regardless of my difficulty with the characterization, I certainly do pick up on the point that LearningResource could potentially be a "more specific type" of any of the entity classes currently set out in schema.org to the extent that anything in the world can be contextualized as a Learning Resource (at least conceptually).  Thinking of it that way obviously presents a more difficult challenge in up-front assessment of the properties we use to particularize multiple schema.org entity classes.  I.e., is the set of properties at http://wiki.creativecommons.org/LRMI/Properties when cast against each of the entity classes you note appropriate and sufficient?

Stuart

[Dolan, Bob]

I'd like to comment on Greg's metadata proposals. Generally speaking, the challenge of tagging is less an issue of large quantities of tags than it is of poor clarity of tags. With that in mind I suggest keeping the metadata fields as-is in the three cases outlined. Specifically:

1) Genre/MediaType/LearningResourceType: These three fields have distinct meanings that should be preserved. That said, I agree there is potential confusion over their roles, especially given their overlap. I think the effort should be on clarifying the fields (and providing examples) rather than eliminating any one of them.

2) Audience/intendedEndUserRole: I don't think the term "intended end user" would confuse anyone. Plus, it disambiguates the "customer" (e.g., teacher) from the user (e.g., student).

3) Competency Terms: requiresCompetencies, teachesCompetencies, and assessesCompetencies all denote very different concepts, ones that are critically important in selecting content. Eliminating any one of these would leave out valuable information about content, and collapsing the categories would just create confusion.

Thanks,
Bob

Bob Dolan, Ph.D.
Senior Research Scientist
Assessment & Information
Pearson
 
413-367-6199
bob....@pearson.com
 
Pearson
Always Learning
Learn more at www.pearsonassessments.com

[John Fontaine]

On Oct 24, 3:29 pm, Stuart Sutton <stuartasut...@gmail.com> wrote:
>  Thinking of it that way obviously
> presents a more difficult challenge in up-front assessment of the properties
> we use to particularize multiple schema.org entity classes.  I.e., is the
> set of properties at http://wiki.creativecommons.org/LRMI/Propertieswhen
> cast against each of the entity classes you note appropriate and sufficient?
>

Refining the concept a bit further. There are two sets of properties
to look at in our object description.

1-The core properties located under the "Thing" namespace. Which of
these are the recommended ones for purposes of describing educational
entities. These might map to most of the "general terms" proposed in
the draft properties.

2-The LMRI specific attributes. This is mostly the Education Specific
Terms, but also the License, isBasedOn and Accessibility items as
these may be very educational specific.

Now consider if we then moved the general properties to be a set of
commonly expected attributes within the "Thing" name space for
educational materials. Then we created a LMRI type for our education
specific terms. Thus as one builds a page containing a Thing (Event,
CreativeWork, Person's resume), one could add an attribute to this
object called "lrmi." lrmi would establish its own namespace to
describe our specific attributes.

LMRI data could be attached at many levels on the page. You might
have a set of resources such as workbooks, interactive games, an eBook
all linked from a single page. That page might also have a list of
contributors which specific subject matter expertise (e.g. tutors,
invited guests, the instructor). Finally the page could have events
such as a conference session, or webinar.

In this model each of those could pick up contextual and relevant LRMI
data. This also creates a relatively light footprint for developers
since one merely has to create one set of objects and then add them as
a property to existing classes for handling other Schema.org data.

JF

[Joshua Marks]

John,

Well said. This is my view as well, the LRMI elements extend the other
Schema Thing elements as needed for our use cases.

Joshua Marks
CTO
Curriki: The Global Education and Learning Community
jma...@curriki.org
www.curriki.org

I welcome you to become a member of the Curriki community, to follow us
on Twitter and to say hello on our blog, Facebook and LinkedIn communities.

-----Original Message-----
From: lr...@googlegroups.com [mailto:lr...@googlegroups.com] On Behalf Of John
Fontaine
Sent: Thursday, October 27, 2011 8:24 AM
To: Learning Resource Metadata Initiative
Subject: Re: Follow-up issues from the Oct 19th LRMI TWG call

[Phil Barker]

On 27/10/11 16:23, John Fontaine wrote:
> On Oct 24, 3:29 pm, Stuart Sutton<stuartasut...@gmail.com> wrote:
>> Thinking of it that way obviously
>> presents a more difficult challenge in up-front assessment of the properties
>> we use to particularize multiple schema.org entity classes. I.e., is the
>> set of properties at http://wiki.creativecommons.org/LRMI/Propertieswhen
>> cast against each of the entity classes you note appropriate and sufficient?
>>
> Refining the concept a bit further. There are two sets of properties
> to look at in our object description.
>
> 1-The core properties located under the "Thing" namespace. Which of
> these are the recommended ones for purposes of describing educational
> entities. These might map to most of the "general terms" proposed in
> the draft properties.
>
> 2-The LMRI specific attributes. This is mostly the Education Specific
> Terms, but also the License, isBasedOn and Accessibility items as
> these may be very educational specific.
>
> Now consider if we then moved the general properties to be a set of
> commonly expected attributes within the "Thing" name space for
> educational materials. Then we created a LMRI type for our education
> specific terms. Thus as one builds a page containing a Thing (Event,
> CreativeWork, Person's resume), one could add an attribute to this
> object called "lrmi." lrmi would establish its own namespace to
> describe our specific attributes.

I don't understand the benefit of doing this compared to just making the
education-specific tags that LRMI comes up with attributes of
schema.org/Thing

>
> LMRI data could be attached at many levels on the page. You might
> have a set of resources such as workbooks, interactive games, an eBook
> all linked from a single page. That page might also have a list of
> contributors which specific subject matter expertise (e.g. tutors,
> invited guests, the instructor). Finally the page could have events
> such as a conference session, or webinar.
>
> In this model each of those could pick up contextual and relevant LRMI
> data.

I think they could if they were attributes of Thing?

I am not sure that the semantics of all the attributes will be the same
when applied to a Person, an Event and a CreativeWork (timeRequired for
a Person??), but let's ignore that for now.

Phil

> This also creates a relatively light footprint for developers
> since one merely has to create one set of objects and then add them as
> a property to existing classes for handling other Schema.org data.
>
> JF

--
Ubuntu: not so much an operating system as a learning opportunity.

[Greg Grossmeier]

Top posting as this is a general comment on this thread/discussion.

In my conversations with Schema.org members, they have asked me where the
terms we are debating will live (the version question of this thread). My
standard reply is "We haven't been making specific assertions about where
they live yet, instead attempting to simply make sure we identify all of
the important terms first. Afterwards, and probably in discussion with
you (Schema.org people), we'll figure that out."

Now, that is a fine initial response, but when asked to elaborate more, I
tell them how I, personally, have been thinking about the terms. What is
normally in my head is that the terms will be additions to
shema.org/CreativeWork, similar to how the rNews addition happened. They
added new CreativeWork terms to CreativeWork (and also a NewsArticle,
which inherits from Article, which inherits from CreativeWork).

When I explain it like that, the response has been: "makes sense."

Visualized:

Option 1, making LearningResource a type of CreativeWork
Thing
- CreativeWork: title, author, etc
-- LearningResource: competencies, agerange, etc

Option 2, making LearningResource a type of Thing
Thing
- CreativeWork: title, author, etc
- LearningResource: title, author, competencies, agerange, etc

Option 3, putting LRMI terms within CreativeWork
Thing
- CreativeWork: title, author, competencies, ageragne, etc

So, what I described above was more like Option 3 than anything.

Now, should we base our work off of a simple "makes sense" statement on a
phone call? Probably not. I'm just laying it out explicitly.

Practical question: If we suggest the creation of a top level Thing
called LearningResource that only inherits from Thing (Option 2), will
that create issues for parsers that are trying to understand the
relationships on a page? For example, you have (in overly simplified
markup):

<div itemscope itemtype="CreativeWork">
<span itemprop="name">Title</span>
<span itemprop="author">John Doe</span>
<div itemscope itemtype itemtype="LearningResource">
<span itemprop="typicalAgeRange">12-15</span>
<a itemprop="teachesCompetencies" href="some_url">Math 3.1</a>
</div>
</div>

Will the parsers be able to understand that even though that Learning
Resource with an age range and competency is a separate thing, it
actually has a title and an author?

Conclusion? If the set of proposed terms is small enough, it could
probably fit in with CreativeWork, thus applying to all of those (videos,
book, article, webpage). We lose the ability to describe an Event or
Person as a learning resource, however. But, based on our previous
conversations those type weren't mentioned as pertaining to LRMI until
recently (changes can happen :)).

Have a good weekend,

Greg

<quote name="Phil Barker" date="2011-10-27" time="18:29:30 +0100">

--

[Greg Grossmeier]

Thanks for your feedback, Bob.

<quote name="Dolan, Bob" date="2011-10-26" time="15:54:34 -0500">

> 1) Genre/MediaType/LearningResourceType: These three fields have
> distinct meanings that should be preserved. That said, I agree there is
> potential confusion over their roles, especially given their overlap. I
> think the effort should be on clarifying the fields (and providing
> examples) rather than eliminating any one of them.

Can you help me by thinking of a couple examples for those 3 terms and
maybe a better definition/description for them than what is there?

Thanks!

Greg

[Joshua Marks]

Stuart,

 

Your points are also well taken. I think this issue of where the Learning Resource fits in the Schema for Schema.org boils down to an question of flexibility and control over the use of the elements over time as the schema itself evolves and changes (Either becomes more structured and semantic, or less so.) As we frequently deal with resources that contain a varied mixture of “Things” that go beyond the context of creative works, we should take the view that the Learning Resource metadata  elements within Schema.org are additive to the media and other metadata for the embedded content being describe for educational use.

 

So to answer your question:

 

“Thinking of it that way obviously presents a more difficult challenge in up-front assessment of the properties we use to particularize multiple schema.org entity classes.  I.e., is the set of properties at http://wiki.creativecommons.org/LRMI/Properties when cast against each of the entity classes you note appropriate and sufficient?”

 

I think the answer is Yes, in the sense the we are saying “This URI represents a Learning Resources with this metadata and it contains  the following other Things (Media, Creative Works, etc.) which each may have this other Schema based I metadata.”

 

As always, my two bits for what it’s worth.  

 

Joshua Marks

CTO

Curriki: The Global Education and Learning Community

jma...@curriki.org

www.curriki.org

 

I welcome you to become a member of the Curriki community, to follow us on Twitter and to say hello on our blog, Facebook and LinkedIn communities.