Re: Toy proposal

Owen,

Extensions ARE NOT proposals for Schema.org ..... that happens LATER.

Think of extensions as "I have a need to extend Schema.org to describe my
Domain better and collaborate with my peers and partners".

Whether an extension gets fully merged and absorbed or partially absorbed
into Schema.org ... happens later and is not guaranteed....what is
guaranteed and promised is sage guidance and collaboration and hosting of
the extension via the Schema.org partners.

Thad
+ThadGuidry <https://www.google.com/+ThadGuidry>

On Thu, Apr 16, 2015 at 9:44 AM, Owen Stephens <owen@ostephens.com> wrote:

> But surely the point isn’t to do things that can be done adequately with
> existing Schema.org types & properties, or to do something that is
> already done via other extensions in a way which is adequate to your needs?
>
> I think it is fair for me to ask:
>
> a) What do we want to say about Toys that can’t already be said adequately
> with non-extended schema.org
> b) Whether proposed extensions in this group are ‘in scope’ for this group
> which is to "discuss and prepare proposal(s) for extending Schema.org
> schemas for the improved representation of bibliographic information”
>
> If we were discussing an extension for representing MARC records in
> schema.org I’d have no objection to Toy and Kit - they would be 100%
> necessary.
>
> I don’t feel like I’m asking unreasonable questions here, but I seem to be
> a lone voice. If no-one else thinks these are concerns then I’ll let them
> drop just noting that I’m yet to be convinced that these particular
> proposals (Toy and Kit) are ones that are required in a ‘bibliographic’
> extension to schema.org
>
> Owen
>
> Owen Stephens
> Owen Stephens Consulting
> Web: http://www.ostephens.com
> Email: owen@ostephens.com
> Telephone: 0121 288 6936
>
> On 16 Apr 2015, at 15:33, Thad Guidry <thadguidry@gmail.com> wrote:
>
> This group can.... do whatever they want...and own an extension for
> whatever purpose they choose, Owen.
>
> I think you might have misunderstood what the Schema extension mechanism
> is for...it is for Domains.
>
> If BIB extension overlaps with MATTEL extension, then that is fine.  And
> if neither of them ever gets merged into Schema.org, then that is also
> going to be just fine.  Extensions can work independently if they want or
> if their Domain needs demand an independent schema model.
>
> Extending off of Schema.org is where the importance lies for everyone
> involved...where there is some alignment to Schema.org's major Type
> hierarchy.  Many extensions can be aligned, and furthermore, they might be
> aligned in different ways, and that is just fine and expected.
>
>
> Thad
> +ThadGuidry <https://www.google.com/+ThadGuidry>
>
> On Thu, Apr 16, 2015 at 9:20 AM, Owen Stephens <owen@ostephens.com> wrote:
>
>> Sure - I wasn’t really debating that as such. So:
>>
>> Why do Toys get some special treatment over all other types of things
>> that also have their specialist properties? I’d like to see some
>> justification beyond “some libraries have toys in their collection”
>> Are we proposing anything in terms of special properties for Toys that
>> mean we need a new type? (I can’t see anything proposed)
>> Does this group include the appropriate domain expertise to discuss the
>> special properties of Toys? If not, shouldn’t we find a way of getting this
>> input?
>>
>> Owen
>>
>>
>> Owen Stephens
>> Owen Stephens Consulting
>> Web: http://www.ostephens.com
>> Email: owen@ostephens.com
>> Telephone: 0121 288 6936
>>
>> On 16 Apr 2015, at 15:15, Thad Guidry <thadguidry@gmail.com> wrote:
>>
>> There are many special properties about toys.
>>
>> The National Institute for Play has some as well as the Consumer Product
>> Safety Commission.
>>
>> If your not a Domain expert then you may often think... no big deal. :)
>> On Apr 16, 2015 4:43 AM, "Owen Stephens" <owen@ostephens.com> wrote:
>>
>>> Ok - but there has been extensive discussion about having lots of
>>> ‘types’ of product and I understood the general advice was to use wikidata
>>> to enumerate product types. What is so special about Toys that they deserve
>>> a type?
>>>
>>> If libraries start marking up as Toy types, how will that compare to
>>> what the commercial sector does when describing Toys? What difference will
>>> this make.
>>>
>>> Owen
>>>
>>> Owen Stephens
>>> Owen Stephens Consulting
>>> Web: http://www.ostephens.com
>>> Email: owen@ostephens.com
>>> Telephone: 0121 288 6936
>>>
>>> On 16 Apr 2015, at 10:27, Wallis,Richard <Richard.Wallis@oclc.org>
>>> wrote:
>>>
>>>  In the spirit of the question, a simple answer is that they are - the
>>> proposed Toy type being a subtype of Product.
>>>
>>>  ~Richard
>>>
>>>  On 16 Apr 2015, at 11:16, Owen Stephens <owen@ostephens.com> wrote:
>>>
>>>  I’m going start with a simple question about Toy...
>>>
>>>  Why aren’t Toys just handled as a schema.org Product?
>>>
>>>  Owen
>>>
>>>  Owen Stephens
>>> Owen Stephens Consulting
>>>  Web: http://www.ostephens.com
>>> Email: owen@ostephens.com
>>> Telephone: 0121 288 6936
>>>
>>>  On 14 Apr 2015, at 22:26, Wallis,Richard <Richard.Wallis@oclc.org>
>>> wrote:
>>>
>>>  Hi all,
>>>
>>>  A few weeks back we discussed how this group or some of its members
>>> could participate as a bibliographic domain group to propose and review a
>>> bibliographic extension to schema.org with the current working name of
>>> bib.schema.org.
>>>
>>>  Since then I have been liaising with Dan Brickley and others in the
>>> main Schema.org <http://schema.org/> group who have been working to
>>> establish the hosting software that enables the extension capability.  This
>>> work is now close to being ready for release.  Dan has indicated that this
>>> provides an excellent opportunity for a bibliographic extension to be one
>>> of, if not the first, enabled and released in this way.  In preparation for
>>> this, Dan Scott and I have put together a candidate set of types and
>>> properties that could constitute an initial bib extension release, which
>>> this email introduces.
>>>
>>>  There are many potential candidates for new/enhanced types and
>>> properties which the finessing and accepting of which would need to be the
>>> subject of some in depth discussion within this group.  To take advantage
>>> of the opportunity to release along with the capability release, however,
>>> we need to agree a starting subset fairly quickly.  To that end Dan and I
>>> have drawn up this initial (1.0) proposal consisting of what we believe to
>>> be things that are fairly noncontroversial.
>>>
>>>  I list the proposed types and properties below with links to their
>>> representation in a development version of the Schema.org
>>> <http://schema.org/> site.  They are in three independent groups of
>>> proposals, for general bibliographic markup; some helpful things for the
>>> physical structure of archives & basic collections; and for comics.
>>>
>>>  We can accept/reject either individual types and properties, or a
>>> whole group, because we need to explore things in more depth and defer
>>> things to a later release.  I would hope though that fairly quickly we
>>> could come to at least a subset of these as an initial release.
>>>
>>>  A reminder that Dan Brickley is still working on the software capable
>>> of handling extensions so please view the content more than how it
>>> currently displays.
>>>
>>>  General Bibliographic Types & Properties
>>>
>>>    - Agent <http://sdo-bib.appspot.com/Agent>
>>>    - Atlas <http://sdo-bib.appspot.com/Atlas>
>>>    - Chapter <http://sdo-bib.appspot.com/Chapter>
>>>    - Globe <http://sdo-bib.appspot.com/Globe>
>>>    - Kit <http://sdo-bib.appspot.com/Kit>
>>>    - Meeting <http://sdo-bib.appspot.com/Meeting>
>>>    - Newspaper <http://sdo-bib.appspot.com/Newspaper>
>>>    - MusicScore <http://sdo-bib.appspot.com/MusicScore>
>>>    - PublicationSeries <http://sdo-bib.appspot.com/PublicationSeries>
>>>    - Thesis <http://sdo-bib.appspot.com/Thesis>
>>>    - Toy <http://sdo-bib.appspot.com/Toy>
>>>    - BookFormatType:AudioBook <http://sdo-bib.appspot.com/AudioBook>
>>>    - BookFormatType:LargePrintBook
>>>    <http://sdo-bib.appspot.com/LargePrintBook>
>>>    - BookFormatType:PrintBook <http://sdo-bib.appspot.com/PrintBook>
>>>    - MapCategoryType:CartographicMap
>>>    <http://sdo-bib.appspot.com/CartographicMap>
>>>    - inSupportOf <http://sdo-bib.appspot.com/inSupportOf>
>>>    - translationOfWork <http://sdo-bib.appspot.com/translationOfWork>
>>>    - translator <http://sdo-bib.appspot.com/translator>
>>>    - workTranslation <http://sdo-bib.appspot.com/workTranslation>
>>>
>>>
>>>  Archive Containers/Collection
>>>
>>>    - BoxContainer <http://sdo-bib.appspot.com/BoxContainer>
>>>    - Collection <http://sdo-bib.appspot.com/Collection>
>>>    - Container <http://sdo-bib.appspot.com/Container>
>>>    - FolderContainer <http://sdo-bib.appspot.com/FolderContainer>
>>>    - Shelf <http://sdo-bib.appspot.com/Shelf>
>>>    - contains <http://sdo-bib.appspot.com/contains>
>>>    - containedIn <http://sdo-bib.appspot.com/containedIn>
>>>
>>>
>>>  Comics
>>>
>>>    - ComicIssue <http://sdo-bib.appspot.com/ComicIssue>
>>>    - ComicSeries <http://sdo-bib.appspot.com/ComicSeries>
>>>    - ComicStory <http://sdo-bib.appspot.com/ComicStory>
>>>    - CoverArt <http://sdo-bib.appspot.com/CoverArt>
>>>    - ComicCoverArt <http://sdo-bib.appspot.com/ComicCoverArt>
>>>    - BookFormatType:GraphicNovel
>>>    <http://sdo-bib.appspot.com/GraphicNovel>
>>>    - artist <http://sdo-bib.appspot.com/artist>
>>>    - colorist <http://sdo-bib.appspot.com/colorist>
>>>    - inker <http://sdo-bib.appspot.com/inker>
>>>    - letterer <http://sdo-bib.appspot.com/letterer>
>>>    - penciler <http://sdo-bib.appspot.com/penciler>
>>>    - publisherImprint <http://sdo-bib.appspot.com/publisherImprint>
>>>    - variantCover <http://sdo-bib.appspot.com/variantCover>
>>>
>>>
>>>  I look forward to comments.
>>>
>>>  ~Richard.
>>>
>>>
>>>
>>>
>>>
>>
>
>