Re: Finalising bib.schema.org 1.0 proposal

To address a few points that have come up in this thread:

Scope of an extension domain / splitting into several extensions

There are three aspects to this.

  1.  Does a proposed term sit well in an extension with a particular name
  2.  Is there a community ready, and most importantly willing, to focus on and maintain a particular subdomain
  3.  Does the term in question satisfy 'a need to describe’ in the sponsoring [of an extension subdomain] community.

Taking comics as an example.  If you have a fairly narrow definition of what bibliographic means, and only address point 1.  it leads towards a conclusion that comics.schema.org<http://comics.schema.org> might be a good idea.  However, taking all three aspects into account and recognising that much of what is in comics is an extension of bib properties anyway — as Dan put it “There's a ton of overlap in the bibliographic domain and the comics domain” — I think pragmatically that there is not much problem with it being part of a bib extension.

I believe that the fact that a term is in a particular named extension is more to do with the group of people working to create and maintain that extension than any implied ontological definition/distinction.

Does the URI for an extension term differ from a core term
No.
Regardless of which extension a term is defined within, its URI will be, as for core terms, http://schema.org/term.  So for example his proposal includes a new Type http://schema.org/Thesis with a new property http://schema.org/inSupportOf.

Despite collecting terms and their definition and justification into extensions, those proposals will need to be approved by the core group to avoid clashes and conflicts between the rest of Schema and is extensions in this flat vocabulary structure.

You could characterise it as extension groups look to the semantics of their extensions, whilst the core group look to the semantics of the core and the syntax of everything.


Is a Globe, etc. a bibliographic item or not
Following on from the above, especially with reference to point 3.

If a suitable term (property or type) does not already exist in core Schema, or an extension to Schema; and there is no obvious group who could be lobbied to include it in their domain; and members of the domain(s) our community represent/support have a need to describe that property or type of thing; then it is within scope of our group to propose it.  In doing so there should always be a view to any term being used elsewhere across the full breadth of Schema.org<http://Schema.org> and its extensions.

Grounding it in the Globe example — There is not already a Globe type, no one else is lightly to define one, members of our community (libraries in this case) do need to describe globes in their collections.

Can we add more CreativeWork subtypes in the future

In my experience, Schema.org<http://Schema.org> has and continues to be a work in progress.  This proposal contains some new CreativeWork subtypes (Newspaper, MusicScore, etc.) these are added under the assumption that others will join them in the future.  The suggestions made by Adrian all look potential for future proposal(s), I’m already thinking that we could do with a Letter type.

The same goes for proposing properties to flesh out types beyond their initial definition.

Do you need properties to justify the need for a subtype
There are several Types in Schema.org<http://Schema.org> that do not have additional properties compared with their super-type.  This is an establish pattern for two reasons.  Either the subtype has no other obvious properties, being a different type is sufficient to differentiate it from the super-type; or the definition is a foundation definition for others to elaborate upon in later releases.

Agent
The proposal for Agent effectively creates a new super-type for Person, Organisation, and BroadcastService.

The initial reasoning being to satisfy the real cases where the creator etc. is unknown as to its type.  In an ideal world the describer of a resource would know if the creator was a Person or an Organization, but as we know in real life that is not the case.  I expect that several other types will become candidates for Agent subtypes in the future, SoftwareApplication for example.

Secondly, it provides a way of rationalising documentation of ranges of some properties to include Agent instead of having to list all the possible types.


This is getting a bit long so I’ll stop for now.

~Richard

On 22 Apr 2015, at 15:09, Dan Scott <denials@gmail.com<mailto:denials@gmail.com>> wrote:

On Wed, Apr 22, 2015 at 8:37 AM, Owen Stephens <owen@ostephens.com<mailto:owen@ostephens.com>> wrote:
I still feel this is rushed. Most of the things here have not been discussed, and the number of people contributing to the discussion is minimal which makes it hard to feel there is community consensus around any of this one way or the other.

I don’t believe we have had a proper discussion about the pros/cons of splitting this into multiple extensions (for which ‘Comic’ could be a candidate).

Specifically on the pros/cons of splitting Comic* out into a separate extension:

* We've previously discussed Comics in a fair amount of depth in this schemabibex community, including the involvement of domain experts like Peter and Henry.  And now that Sean has joined the discussion and given it a reasonably positive response, it seems like it is pretty much ready to roll. At least, ready for a 1.0 (or maybe it should be 0.1 given the state of the supporting code, etc) "extension" release, given that a theoretical advantage of an extension is that we should be able to iterate more quickly than core schema.org<http://schema.org/> can (e.g. tweaking property descriptions).

* There's a ton of overlap in the bibliographic domain and the comics domain. It seems like splintering the discussions and extensions would just make for more confusion than is necessary.

Dan