Re: An initial proposal for bib.schema.org

Great this is exactly the type of discussion I expected and hoped [I think ;-) ] this proposal would trigger.

To address a few of the issues raised.

Timeline - as I mentioned I am hoping to take advantage of releasing at least a basic initial extension alongside the release of the extension capability itself from Schema.org<http://Schema.org>.  Comparing schedules that would mean having something agreed by the end of next week.  As I said in at the beginning of this thread, to that end Dan and I went for a set of proposal at the hopefully uncontroversial end of the spectrum - we dropped many possibilities in doing this.

As this discussion has shown, some proposals may be too controversial, or at least may require sufficient further discussion, to make it likely to not fit in with our timescales.  No problem with that we can defer them to later releases.  To track what is in/out/deferred I will produce a wiki page later today.

When is a Toy not a Product - When drawing up the list several potential subtypes, that trawling library data identified, were dropped. Things such as DVD, LPRecord because they were just individual types of product (carrier in library parlance).  Game was dropped because it has already appeared in the Schema.org<http://Schema.org> core.  Toy was left in as it was more a category of product, many products puppet,  jigsaw, etc., can also be a toy.  The proposal, recognising this, proposed  a Product subtype with no extra properties.  May be at a later date further her work would suggest ageRange an other Toy properties.

One counter option could be to define a Toy as the Product that it actually is (puppet, etc.) and multi-type it as also being a <http://www.productontology.org/doc/Toy>

Examples - apart from the comic stuff, examples are sadly lacking from the proposals.  A situation I hope to go someway towards correcting over the next couple of days - any offers from others would be greatly accepted.

Justification for inclusion in the bib extension - The bib extension should not be a proxy for traditional library cataloguing practices and concerns.  I believe its remit, usefulness and utility should be much broader than that, being relevant to publishers, aggregators, retailers, collectors, consumers and others, as well as libraries.  A useful start point, however, is to see what librarians have catalogued over the years as the tend to have collected most of what the rest of the world has published in the broadest sense.  An analysis of the 300+ million records in WorldCat.org<http://WorldCat.org> resulted in open Schema.org<http://Schema.org> extension - BiblioGraph.net<http://BiblioGraph.net> - a filtered view of this being used as the seed for this proposal.

Just because librarians have catalogued in a certain way nevertheless is not justification for being in the bib extension.  It is just a clue that it is worth consideration.

Meeting - Is just one of these clues.  The fact that a Meeting is an important consideration as some form of contributing Event/Agent (?) in the creation of a  work is well recognised especially in the library community.  The question being how to represent it - I think we need some examples and a bit of pragmatism to decide on this one.

~Richard

On 17 Apr 2015, at 09:32, Owen Stephens <owen@ostephens.com<mailto:owen@ostephens.com>> wrote:


On 17 Apr 2015, at 05:59, Tom Morris <tfmorris@gmail.com<mailto:tfmorris@gmail.com>> wrote:
<snip>
I'd hate to see it become an unorganized dumping ground for a couple of centuries of cataloging cruft.  The fact that libraries lend toys and "kits" (and museum passes and tools and all manner of other stuff) doesn't make them creative works or in any way bibliographic.  Focus on the bibliographic please.
An unsurprising +1 to this from me…


In a similar vein, I hope "Meeting" isn't on the list because someone's going to propose that a meeting can author a creative work.
This particular point hadn’t occurred to me, but I think it points to an issue with the overall Extension proposal. To give these things proper consideration I think we need more information. I’m trying to think through what I’d want to see. I think something like:

* Gap identified in current schema.org<http://schema.org/> - what is it that we need to do that isn’t currently supported
* Why it is important to fill the identified gap - why the extension is needed
* How proposed type/property fills that gap
* Example of how type/property would be used in relation to the gap

I think this would allow us to focus discussion on:

* Do we agree there is a gap and if not how would current schema.org<http://schema.org/> be used (and counter arguments etc.)
* Do we agree that it is important to fill the identified gap
* Alternative proposals for filling the identified gap
* Counter examples showing how other approaches might work

  Tradition doesn't make it right.
I think there is a line to walk here. I totally agree that tradition doesn’t make something right. However, I also think that schema.org<http://schema.org/> has tried to be pragmatic in terms of what can be achieved based on existing data and markup and I think we need to do the same in this extension. If we define an approach that we can’t implement from current data then I think this is as much of a problem as if we define an approach which includes all the ‘cataloguing cruft’.

Tradition doesn’t make it right, but it may end up forcing certain compromises on us. I’m OK with that I think.

Owen