Tag Archives: DublinCore

Some recent Work (Expression, Manifestation, Item)

Other, , , ,

I blame John. He got me interested in FRBR, and long ago he helped me with a slightly mad attempt at FRBRizing Learning Resources. Of course FRBR is for Bibliographic Records, isn’t it? and according to several people I respect it doesn’t work (though other people whom I respect equally say that it does). Personally I always struggled around the expression/manifestation distinction for many types of resource, and always wanted it to play more nicely with the resource/representation approach of the WWW Architecture. But I did keep coming back to it when trying to explain the need to be clear about what exactly was being described in RDF, for example. If you’ve heard me go off on one about Romeo and Juliet, and the play-on-the-stage vs play-on-the-page, or the difference between novels and books, then you’ll know what I mean. So that’s why I got involved in the W3C OpenWEMI working group, certainly I didn’t contribute any expertise on WEMI that wasn’t already covered, but I hope I helped with some of the RDF stuff because I’ve certainly learnt a lot, and now:

Dublin Core announces openWEMI for community review

openWEMI is an RDF vocabulary based on the concepts of Work, Expression, Manifestation, and Item (WEMI) that were first introduced in the Functional Requirements for Bibliographic Records (FRBR) document produced by a working group of the International Federation of Library Associations (IFLA). That work and subsequent versions form the theoretical basis for library catalog metadata.

This DCMI work product defines a minimally constrained set of classes and properties that can be used in a variety of contexts. Unlike the IFLA work, openWEMI elements are purposely defined without reference to library catalog functions….

See the news item on the Dublin Core website for more information about how you can comment on the work.

Kudos to Karen Coyle for leading us through this work, and thanks to all the other working group members.

Dublin Core Tabular Application Profile

Application Profiles, , , ,

Over the last year or so I have been contributing to a Dublin Core Metadata Initiative Interest Group, lead by Karen Coyle, that has been drafting recommendations on how to create and document application profiles in simple a tabular format. At the end of last year we had a webinar presenting the work so far, which now available on YouTube. For me the really useful thing about this approach, which we are calling DC TAP, is that it is a human-friendly approach that also lends itself to machine processing­—at the end of the webinar recording Tom Baker demos a python script that will take a tabular application profile exported in CSV format and turn it into ShEx that can be used to validate data.

Continue reading →

LRMI balloon debate at #DCMI16 Metadata Summit, Copenhagen

LRMI, ,

I summarised the presentations given at the LRMI workshop “Building on Schema.org to describe learning resources” at the Dublin Core conference in my previous post, this post is about the discussion part of the workshop. The discussion was organised along the lines of a balloon debate:

A balloon debate is a debate in which a number of speakers attempt to win the approval of an audience. The audience is invited to imagine that the speakers are flying in a hot-air balloon which is sinking and that someone must be thrown out if everyone is not to die. Each speaker has to make the case why they should not be thrown out of the balloon to save the remainder.

https://en.wikipedia.org/wiki/Balloon_debate

Our “balloon” is a metaphorical one, it stands for the volunteer effort that maintains LRMI (LRMI seeming somewhat like a balloon in that it is kept going by hot air), and instead of carrying people it is trying to carry out work that will help people describe learning resources. While it is by no means sinking, like a real balloon LRMI can only sustain a certain (work-)load, and so we need to be selective in the work which is taken on. This exercise was intended to provide LRMI with ideas about which work to prioritize, while providing those who take part with information about the future directions that are open to LRMI.

Debate format

The debate proceeded through three rounds, the first round was about choosing candidate ideas for future work, the second eliminated those which seemed least feasible, and the third was to select the highest priority ideas. On the day we didn’t really get to the third round, but the results were nonetheless interesting.

The Ideas

We started with the following ideas, seeded by myself with help from other members of the LRMI task group (especially Stuart Sutton who provided several of the descriptions).

1. Structured, controlled vocabularies for LRMI properties.
Several key LRMI properties take text for their expected value type. The use of free text for properties such as learningResourceType makes it difficult to compare data from different providers. Where there are suggested values mentioned in the LRMI spec for these, the LRMI Task Group is already working to provide definitions of terms in RDF (as SKOS Concepts). This suggestion is a continuation of this work, to try as far as possible to provide controlled vocabularies for relevant LRMI properties.
2. Drop the Alignment Object for the most common alignment types
The mechanism of indicating how a resource relates to an educational framework involves a level of indirection which is both arcane and potentially powerful, however it’s full power is not fully developed. The suggestion here is that the indirection be removed by creating properties for those alignment types which are clearly important. So, for example, it is often important to state the educational level of a resource (e.g. in terms of Grade Level). Currently this would be an educationalAlignment with an AlignmentObject having alignmentType of educationalLevel. The indirection of the AlignmentObject could be removed if there were a property of a learning resource called educationalLevel referencing directly a point in a grade level framework.

Figure 1a: representing an educational alignment with an alignment object. The alignment type property of the alignment object can set to specify the nature of the relationship, e.g. that this represents the educational level of the resource.Figure 1a: representing an educational alignment with an alignment object.
The alignment type property of the alignment object can set to specify the nature of the relationship, e.g. that this represents the educational level of the resource.

simplifiedalignment-simpleschemagraphFigure 1b:  a possible way of representing an alignment such as educational level of the resource more simply. Note: the value provided could be text or a URI; representing the relationship of the node to an educational framework is not yet solved in Schema.org.

 

3. Develop the Alignment Object to be more expressive
The mechanism of indicating how a resource relates to an educational framework involves a level of indirection which is both arcane and potentially powerful, however it’s full power is not fully developed. The suggestion here is that properties be added to the AlignmentObject to allow additional information about the alignment between a resource and a point in an educational framework. This additional information may include factors such as: who asserts that the alignment holds, what evidence they have for this alignment, how good is the alignment.
4. Recommendations for referring to educational frameworks
From the point of view of facilitating resource discovery the relationship between a resource and an educational framework is key. Showing how a resource relates to a framework which is understood by educators and learners allows them to find resource suitable for their needs. This may be manifest in discovery interfaces as faceted search or browse categories. One problem is identifying the relevant frameworks for different types of educational alignment in different educational contexts (e.g. what is the Scottish equivalent of K-12 for educational level?). Another problem is that variation in how these frameworks are expressed in LRMI metadata makes creation of such services more difficult than it need be (what is the framework name for K-12? What URIs are best to use?). We could help by creating an inventory of frequently used educational frameworks and recommendations on how to refer to them.
5. Declare a “Learning Resource” type
Currently, a Learning Resource is not formally declared in the schema.org schema as a subtype of CreativeWork. Instead, it is inferred that a Learning Resource is a kind of CreativeWork since the LRMI properties were included as part of the CreativeWork type. The lack of an explicit LearningResource subtype to CreativeWork makes it difficult for some doing markup or implementing systems using schema.org to recognize that schema.org in fact supports description of learning resources. They see EducationEvent as a subtype of Event, but no LearningResource as a subtype of CreativeWork.
6. Define a minimal subset of schema.org for describing learning materials
The schema.org schema is quite large and can be intimidating for some wanting to define minimally viable learning resource descriptions–e.g., where to begin, what properties are most important, how should they be used. Publishing a suggested profile of schema.org that defines a minimaly viable learning resource description while leaving open the addition of other properties needed with a particular use, might assist implementers needing a means to jumpstart development of their own profile based in schema.org.
7. Create support materials explaining LRMI properties
Recently, examples of how to use the AlignmentObject as well as the LRMI properties of CreativeWork have been added as ‘footers’ to the relevant schema pages at schema.org. While an excellent beginning, these additions are not enough. Other types of support materials for describing learning resources using the LRMI properties and classes need to be defined, developed, and published. Such materials might include a one-stop “primer” that combines narrative with examples and covers the inevitable points in usage where subjective decisions must be made where there are alternative legitimate paths forward.
8. Collate information about existing LRMI implementations
Specifications always need to be interpreted in order to be used in specific contexts, and however much normative and informative material is provided, we cannot hope to cover all contexts. One way that people implementing a specification can make choices that do not lead to unnecessary divergence is by referring to other implementations from similar contexts. LRMI could facilitate this by collating information about where these implementations can be found. This may also be useful in monitoring the uptake of the specification, identifying problems commonly encountered and providing examples of good practice.
9. Create an editor for LRMI metadata
Several tools exist that can create LRMI metadata within the scope of a single project or service’s needs. What is suggested here is that LRMI create, assist or promote the creation of an editor that can serve as a reference implementation: independent of the choices that would need to be made for any use in practice but flexible enough to be tailored practical use and, importantly, illustrating good practice in the implementation of LRMI.

The voting

voting from LRMI workshop DCMI CopenhageIn the end we discussed and voted on the issues of which ideas seemed most appealing and then, after eliminating those ideas which were not popular, we discussed and voted on the ideas that seemed least feasible, then had a short discussion about the results. We kept a tally of the votes on a flip chart: green ticks for ideas we thought attractive, red ticks for those we thought least feasible.

The ideas most liked were:

  • Structured, controlled vocabularies for LRMI properties,
  • Define a minimal subset of schema.org for describing learning materials, and
  • Collate information about existing LRMI implementations.

As was pointed out in the discussion, there are relationships between the ideas which mean that some other ideas become easier if these are achieved first (e.g. a general purpose editor becomes easier if you have agreed a general purpose subset of schema for it to edit).

Those ideas which we thought most difficult to achieve were

  • Structured, controlled vocabularies for LRMI properties and
  • Declare a “Learning Resource” type.

The specific issues with both of these centred around achieving agreement or consensus on terms and definitions.

I’m pretty sure that everyone involved in LRMI will see something in these results that they think a sensible outcome and something which raises an eyebrow or two. I’m also fairly sure that it won’t be the same things for everyone.. which is to say, the discussions will continue.

So what now?

Some of the ideas discussed are based on work that individuals or groups involved in LRMI are already scoping out. As a group we have made a start on formally describing some values for use with LRMI terms as SKOS concepts (see the DCMI/LRMI Github repository).  I have had a masters student work on creating a subset of schema.org for learning resources. There is an editor for LRMI in the works, which looks like it could meet the sort of requirements described above. And as I described in the presentation I gave at the workshop, there is work describing how LRMI is used. So hopefully we will be able to make progress on some of these ideas.

As I said during the workshop, LRMI is a volunteer effort. People work on whichever aspects of it interests them. If you are interested in any of the ideas described above, or have some other ideas that you think would be valuable, please join us and I hope will be able to achieve more together.

LRMI at #DCMI16 Metadata Summit, Copenhagen

LRMI, , ,

I was in Copenhagen last week, at the Dublin Core Metadata Initiative 2016 conference, where I ran a workshop about LRMI entitled “Building on Schema.org to describe learning resources” (as one of my colleagues pointed out, thinking of the snappy title never quite happened). Here’s a quick overview of it.

There were three broad parts to the workshop: presentations on the background organisations and technology; presentations on how LRMI is being used; and a debate where attendees got to think about what could be next for LRMI.
Continue reading →

On LRMI moving to Dublin Core

cetis, LRMI, ,

At last, it is official:  “effective October 23, 2014, leadership and governance of the Learning Resource Metadata Initiative (LRMI) […] have transferred from the Association of Educational Publishers and Creative Commons to the Dublin Core Metadata Initiative (DCMI).”

This represents the end of LRMI as a project, and the start of it as a member of the family of stable-but-evolving educational metadata specifications, one which is maintained under the governance protocols of DCMI.  This does not mean that LRMI is being merged in some way with Dublin Core’s well known metadata element set or terms; DCMI is more than its specifications, it is (as it says on its website banner, with my emphasis) a metadata community “supporting innovation in metadata design, implementation and best practices”. The longstanding high regard with which the DC Metadata Element Set and DC Terms are held is testament to the care and expertise that the DCMI community devotes to specification development and curation.  LRMI will now benefit from that same care and expertise. It will also benefit from representation among other educational technology and metadata specification and standardization bodies, for example through the Digital Learning Metadata Alliance.

This does not mean that activity and development of LRMI will stop. It won’t (I hope), but new developments will be subject to careful scrutiny and well governed procedures leading to community acceptance. The scope and pace of new developments won’t be prescribed by project proposals, workpackages and deadlines agreed with funders, they will depend on people articulating needs and solutions that they are prepared to put effort into developing. The funding was necessary to get the initiative up and running, the funders have been great in allowing the project to be responsive and agile in ascertaining and meeting the needs of key stakeholders. The funders never dictated how the project met its aims. The project would not have reached this successful end point had that not been the case. For any initiative to continue after the initial project funding ends is a challenge, but I believe LRMI as part of DCMI is well placed to meet that challenge, now onus is on the community who use LRMI to take it forward by defining new areas for building consensus within the DCMI governance framework and by bringing new resources to this effort.

Transfer to DCMI does not mean the end of the involvement of many of the individuals who have worked on LRMI in the past. The task of setting up LRMI within DCMI is being undertaken by a task group that includes Lorna M Campbell and me, extending the work that Cetis were funded to undertake in phase 3 of the funded project, Stuart Sutton, Dan Brickley, Michael Jay and Steve Midgley all of who have been active throughout the project. Beyond that, one of the reasons why DCMI was felt to be an appropriate home for LRMI is the fact that there are no barriers put in the way of anyone who wants to contribute to their work on specifications, so I hope that we will see many others who have contributed to LRMI in the past joining us.

Many thanks to my colleagues at the Association of Educational Publishers, Creative Commons and the Dublin Core Metadata Initiative who have made this possible.

Where to put your EPUB metadata

cetis, LRMI, , , ,

Even in the knowledge that current mainstream EPUB readers and applications for managing eBooks will most likely ignore all but the most trivial metadata, we still have use cases that involve more sophisticate metadata. For example we would like to use the LRMI alignment object in schema.org to say that a particular subsection of a book can be useful in the context of a specific unit in a shared curriculum.

So, without evaluating pros and cons, starting from the most basic/most common, what are the options? This is a summary takes information from Garrish and Gulling, EPUB 3 Best Practices, OReilly 2013, (which I take to be authoritative and also as an example of best practice with regard to the metadata in the epub file) as well as the EPUB 3.0 Publications and Content Documents specifications. Any comments would be greatly appreciated.

1. Simple Dublin Core

Within the OEPBS directory of an unpacked EPUB3 is the content.opf file. It pretty much equates to the manifest of an IMS Content Package. The top-level element is <package> and <metadata> is a required first child of <package>.

The default metadata vocabulary is the Dublin Core Metadata Element Set (DCMES, simple DC), with prefix dc:. Three elements are mandatory–title, identifier and language–others are optional. For example, in /OEPBS/content.opf

<?xml version=’1.0’ encoding=’UTF-8’?>
<package xmlns:dc="http://purl.org/dc/elements/1.1/ [...]">
    <metadata>
        <dc:identifier>urn:isbn:9781449325299</dc:identifier>
        <dc:title>EPUB 3 Best Practices</dc:title>
        <dc:language>en</dc:language>
        <dc:rights>Copyright © 2013 Matt Garrish and Markus Gylling</dc:rights>
[...]

2 Other metadata schemas

The package element has a prefix attribute that may be used to declare prefixes for metadata schemas other than DCMES. Four vocabularies are reserved, i.e. the prefix may be used without a declaration: dcterms, marc, onix and media (the vocabulary used for EPUB3 media overlays). Example

<dcterms:title>EPUB 3 Best Practices</dcterms:title>

Other vocabularies may be used providing a prefix and a URL in a way so similar to xmlns that is makes you wonder why they didn’t just use xmlns.

<package prefix="prism: http://prismstandard.org/namespaces/basic/3.0/" [...]>

3 the meta element

If used without the refines attribute (see below) the meta element can provide information about the package as a whole, e.g.

<meta property="dcterms:title">EPUB 3 Best Practices</meta>

I have no idea what would be the benefit of this over <dcterms:title>.

4 Refining metadata elements: id attribute and the meta element

The id attribute can be used to provide an identifier any element in the metadata that it may be refined. One example of this is mandatory, i.e. that one occurrence of the dc:identifier element must be the publication identifier:

<dc:identifier id="pub-identifier">urn:isbn:9781449325299</dc:identifier>

In general the refinements are described using the meta element with the refines attribute and a property attribute that specifies the nature of the refinement. It’s kind of like RDF reification. The default vocabulary for the property attribute includes “file-as” – an alternative string for a name to be used when filing, “identifier-type” – a way to distinguish between different identifiers, “meta-auth” – the authority for a given instance of metadata, “title-type” – which of the six forms of title being provided.

<dc:creator id="1234">Matt Garrish</dc:creator>
<meta refines="#1234" property="file-as" id="5678">Garrish, Matt</meta>
<meta refines="#1234" property="role">Author</meta>

Terms from other vocabularies may be used for “property” so long as a prefix is declared.

Refinements may have ids and so may be refined.

<meta refines="#5678" property="meta-auth">Phil Barker</meta>

So and so you can make statements about your metadata statements to you heart’s content (though including the whole of the linked data graph in each epub would be silly).

The scheme attribute may be used to identify the controlled vocabulary from which the meta element’s value is drawn. For example, if the identifier is a DOI (which in onix is apparently entry 06 of codelist 5) you can have

<dc:identifier id="pub-id">urn:doi:10.1016/j.iheduc.2008.03.001 </dc:identifier>
<meta refines="#pub-id"
      property="identifier-type"
      scheme="onix:codelist5">06</meta>

Or, using the marc relator value Aut to specify author

<meta refines="#1234" property="role" scheme="marc:relators">Aut</meta>

5 Sub-package level metadata

The id attribute may be used to provide an identifier of an subelement of <package> or any element in the XHTML content documents, down to a span element around a phrase, word or character. So a chapter may have id=”chap1″ then we can use meta elements in the metadata to describe it seperately from the rest of the epub

<meta refines="#chap1" property="prism:contentType">bookChapter<meta>

6 Links to metadata records

The link element is an optional, repeatable subelement of <metadata>, “used to associate resources with a publication, such as metadata records” The metadata may be within package or anywhere on the www.
Example

<link rel="marc21xml-record" href="pub/meta/nor-wood-marc21.xml" />
<link refines="#chap1" rel="ex:schema_org-record"
      media-type="application/ld+json"
      href="http://example.org/nor-wood-lrmi.json" />

Metadata embedded in the XHTML5 content

As far as I can see the EPUB3 specs are mute on metadata in HTML of the content documents, e.g. as html:meta elements or as microdata or RDFa, there doesn’t seem to be any reason why one should not put metadata here. I wouldn’t expect any EPUB system to look that deeply into the package but it would be a good approach to helping the metadata travel with the resource if the EPUB is disaggregated and passed into a non-EPUB3 CMS.

LMAP Scoping Study draft report

cetis, LMAP, ,

Some time back I started a scoping study into a potential Learning Materials Application Profile (LMAP) for the JISC. Well, I have at last written a draft report that is fit to be read by others, for comment.

It is rather long, and I don’t expect that anyone will want to do any more than look at the section that is relevant to your own interests. But if anyone is interested in taking a sneak preview then do please have a look and let me know of anything you spot that is wrong or misleading. (In my opinion it gets better as it goes along.)

I have some more work to do on it, filling in references, adding acknowledgments etc, that will take me a couple of weeks at least. Any comments received before I get those finished will be considered in the final report submitted to JISC.

Update, 11 Dec 2008: Thank you for your comments. The report as submitted to JISC is now available. I’m hoping they don’t want too many changes made.

A short update on Metadata specs

cetis, ,

As promised when I wrote the short update on repository specs, here is the complementary information about what’s been happening over the last few months with education metadata specs. Brief version: some minor changes to the IEEE LOM have been agreed; closer harmony between the LOM and Dublin Core is in the offing; and if you think that DC comprises 15 elements you need to look at it again.

Continue reading →