Schema Course Extension Wiki Navigation
Main Page
Outline use cases
Example sites
Other useful links
Community group home page
email list for group
schema.org Git hub issue

Also available: a recording of the meeting (edited to remove chat while we were getting started).

Roll call:

Phil Barker, Heriot-Watt Uni
Alan Paull, freelance information manager
Richard Wallis, independent consultant
Dan Brickley, Google
Stuart Sutton, Dublin Core Metadata Initiative (DCMI)
Jim Goodell, Common Education Data Standards (CEDS)
Rafael Jimenez, Elixir
Vicki Holland, Google
David Weinberger, independent writer
Abdulaziz Aldaej, Prince Sattam Bin Abdulaziz University
Jason Haag, ADL
Jeanne Kitchens, Southern Illinois University, Center for Workforce Development
Joe Karaganis, The American Assembly, Columbia University
Michelle Brennan, OER Commons, ISKME
Eva Méndez (Universidad Carlos III de Madrid)
Nate Argo, Southern Illinois University, Center for Workforce Development
Robby Robson, Eduworks
Miquel Centelles, Universitat de Barcelona

What makes a good extension for schema.org, Richard Wallis

Schema.org has taken input from the outside world since the first release. Contributions relate to the best way to describe resources on the web in order to make them more discoverable. Contributions can be small changes to wording or large sections (e.g. GoodRelations contributed to eCommerce section). Richard leads community group which is contributing bibliographic-related terms.

Three ways to contribute to schema.org: suggest a change directly and two forms of extension: hosted and external. Hosted extensions are on the schema.org website and part of the schema.org namespace, e.g. Bibliographic Extension. External extensions allow anyone to put up their own extension on the own site with their own domain name. Whether an extension should be hosted or external will depend on how generally useful or domain specific it is.

In Richard’s experience, best approach is to take “several bites of the elephant”--trying to get the community to agree to a large extension with many new properties and types is problematic. Getting agreement for simple extension with clear need and benefit is easier, and then you can build on that.

Another factor that is important is where would the terms be used; extensions which are likely to be used across many sites have more chance of success [Dan Brickley qualified that use in a few key site could be successful, e.g. use of a course extension by MOOC providers.] A small extension that is well used can be extended based on usage.

Finally, trying to reproduce existing domain ontologies in schema is likely to suggest a lot of things that schema doesn’t do. The approach that seems to work is to temporarily forget about any vocabulary you knew before and try to describe the resources with what is in schema.org already trying to get the best description you can with these non-specialist terms, even if they don’t fit exactly the terminology in your domain.

How to proceed

Phil Barker: Currently, we have had discussions in various places, a couple of proposals, summarised in a road map. Suggest work around specific use cases and requirements to check where there is existing data and to check code / modelling against the use cases. Is there agreement on what is best way to go forward? How can we work with the proposal, e.g., from Wes Turner to match it against use cases and discuss detailed issues?

Dan Brickley: Could use multiple issue more effectively. In github markup can use - [ ] to create to do list. Keep substantive discussion in issues so that issue is a problem and pull request is a way to address that problem. Was hoping that Vicki’s draft would be starting point for discussion; not sure how close Wes’s pull request is to that proposal.

Phil: Would be useful to have human readable build which included Wes’s pull request.

Dan: can do this based on branch of schema.org in Wes’s fork of schema.org repository. Talk about details off-line. What we need is: any changes to existing properties and for new stuff, a name and definition and place in the hierarchy (e.g. Course as intangible or as CreativeWork). Try to anchor everything in examples, ideally concrete examples which shadow real sites on the web.

Phil: Would a tracking issue be useful?

Dan: yes, could create one for community group. Clear issue tracking progress of this group. Act a liason between schema.org and this group. Subissue within that (new or existing) as needed.

Action: Phil - create issue in github to act as liaison with this group.

Richard Wallis: use mailling list for this group to discuss strategic issues, e.g. whether a Course is a CreativeWork, what do we do about Course Sections/Offerings, how do they map to Events. Can use community group wiki to collaborate on examples, building around the proposal.

Phil: we have some use cases developed from LRMI. Move those on to wiki to that they are shared by the community group, and link to git hub issues as relevant (or check boxes in to do list) Dan: I would encourage the group to adopt this document as working document. And then work with Vicki’s proposal as a potential solution. Impression is that Wes’s work is close to this.

Michelle Brennan: Document is a lot to take in. Could we have some time to consider it.

Phil: I’ll simplify the document, move it on to the wiki, and request comments.

Action: Phil put proposal on wiki. Initiate discussion on list

Richard: Looking at doc, remember we are creating a spec for markup language not implementing it in a system

Phil: agreed, view terms like use cases and requirements loosely in that light, not in terms of specification for system to be built.

Next call:

We will proceed from here via shared documents, email, github, and have a call if we need one.