Why Extend

• What is our approach to schema.org?
• How will help users?

For inspiration see http://schema.org/docs/meddocs.html

Extensions should be analyzed not only relating to libraries but in terms of non-library uses. Where possible, extensions should be proposed in a way that other communities needing the functionality could make use of the terms.

Before extending, we should look at existing schema.org properties to see if they can be re-used.

Appropriate copy problem revisited

We need to be able to describe:

• What a service has to offer (in the library world 'holdings')
• The characteristics of those that can typically make use of the service (whether based on geo, IP range, personal subscription, etc.)

Knowing that I can access a film via my existing NetFlix subscription is just as valid an outcome as knowing that I can buy it from Amazon or borrow it from my local library. See also the Kindle Lending Library, Spotify, Pandora, etc. etc.

Scholar.google.com recognizes user IP address ranges and serves up links that lead directly to electronic resources licensed by the corresponding institution. Imagine rewarding search engine users with links to instances they can access at their affiliated institutions.

Specific object types

define some more object types that can be surfaced in schema.org beyond the current list at the bottom of http://schema.org/CreativeWork - Jeff Young touched on this in the kick-off call, if I recall correctly. For example, surely something like "Journal" or "Periodical" (perhaps reflecting a collection of http://schema.org/Article - similar to how http://schema.org/Blog represents a collection of http://schema.org/BlogPosting ) needs to be added...