Minor additions to Bib extension

[RichardWallis]

Over recent months I have been working with several large national and international library organisations on how they would represent their collections using Schema.org. Overall I have been pleased with the ability of the vocabulary to describe the resources.

However I have identified a small set of circumstances that are difficult to describe using Schema. To that end I make the following proposals to enhance the bib.schema.org extension.

• New Type Manuscript (subtype of CreativeWork): "A book, document, or piece of music written by hand rather than typed or printed."

• New Type Poster (subtype of CreativeWork): "A large, usually printed placard, bill, or announcement, often illustrated, that is posted to advertise or publicize something."

• New Type Drawing (subtype of CreativeWork): "A picture or diagram made with a pencil, pen, or crayon rather than paint."

• New Type SheetMusic (subtype of CreativeWork): "Printed music, as opposed to performed or recorded music."

• Extend domain of publisher to include PublicationEvent. Libraries commonly describe publication events which link together a CreativeWork, publishing Organization/Person and the publication [Event] date.

Like others, I am reticent to propose/recommend ever increasing numbers of subtypes to allow categorisation of a particular domain. However in this case, I believe we are close to covering the vast majority of types that this domain commonly describes. I therefore propose the above to attempt to bring this extension closer to completion.

[osma]

In our collection we have quite a number of records of type StillImage. Unfortunately the records don't tell, at least not in a structured way, whether these are Drawings or for example Photographs, so I cannot represent these using the current schema.org types or the proposed Drawing type.

Would it make sense to group Drawing, Photograph, Map and VisualWork (and perhaps others?) under a common CreativeWork subtype such as StillImage or just Image? There is ImageObject, but it is described as "an image file" which is not what our records mean. They can represent photographs, photographic books, paintings etc.

Generally +1 for everything proposed above.

[RichardWallis]

I have some sympathy with this view, however I think that such structure needs deeper thought and consideration.

Do we need a MovingImage super-type for video, movie, etc. and a Sound super-type for speech, music, sound-effects etc.?

Perhaps an expansion of the description of ImageObject would be a more pragmatic approach "An image file or object"

[thadguidry]

@RichardWallis No, don't expand the description of ImageObject...it will confuse things against the already existing CreativeWork:image property that expects a type of ImageObject. We already have at least 3+ ways for @osma to handle his use case.

@osma Essentially, all of those types are CreativeWorks. There is no reason to subtype for your use cases. But if you don't want to use that easy route, you can use VisualArtwork:artform (don't think to much in the Art part, because anything can be Art) or if you don't want to express as an Art form because it just feels weird for that Thing, then you can use CreativeWork:additionalType and point to a URL that holds a value of "Media" or "Image". If you do want to really subtype your use cases, then any of these would give you the concept of a "Non-written CreativeWork that is visual in nature", but I am sure there probably is already an additionalType out there in the world that you could use that already has that similar Type definition. Go look for it and use it.

[osma]

@thadguidry Thanks for the advice. Indeed I was already looking at using additionalType to link to either the RDA Vocabulary or BIBFRAME (or even both).

I also looked at the Content-Carrier proposal, which suggests linking to Wikipedia through the Product Types Ontology, but it didn't seem to work very well for me because many of the types are not represented as Wikipedia pages since the perspective is so different - e.g. MixedMaterial is a Work subclass in BIBFRAME, but a Wikipedia page about "mixed material" wouldn't make sense.

[Dataliberate]

@thadguidry <https://github.com/thadguidry> On reflection I agree with your thoughts about not expanding the description of ImageObject - I was only thinking out loud. @osma <https://github.com/osma> The [librarian] Content/Carrier view of the world does tend to attract some confusion when trying to apply it to Schema, I haven’t checked but I wonder if WikiData may be a better approach than productontology.org. Another approach maybe worth considering would be using URI values from the Library of Congress Content Types <http://id.loc.gov/vocabulary/contentTypes.html> & Carriers <http://id.loc.gov/vocabulary/carriers.html> sets, in addition to Schema.org Types (at least CreativeWork). ~Richard Richard Wallis Founder, Data Liberate http://dataliberate.com Linkedin: http://www.linkedin.com/in/richardwallis Twitter: @rjw

…

On 30 November 2016 at 08:48, Osma Suominen ***@***.***> wrote: @thadguidry <https://github.com/thadguidry> Thanks for the advice. Indeed I was already looking at using additionalType to link to either the RDA Vocabulary or BIBFRAME (or even both). I also looked at the Content-Carrier <https://www.w3.org/community/schemabibex/wiki/Content-Carrier> proposal, which suggests linking to Wikipedia through the Product Types Ontology, but it didn't seem to work very well for me because many of the types are not represented as Wikipedia pages since the perspective is so different - e.g. MixedMaterial <http://id.loc.gov/ontologies/bibframe.html#c_MixedMaterial> is a Work subclass in BIBFRAME, but a Wikipedia page about "mixed material" wouldn't make sense. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1448 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHVdIEd-DWa8f7h4oxgWnImAlTiPMfTSks5rDThEgaJpZM4K-49j> .

[thadguidry]

@osma Wikidata is the correct place to create a new topic page if there isn't one already that fits your need. I myself had to create many new topic pages just to get the Schema.org - Wikidata mapping done :)

[RichardWallis]

Implemented in release 3.5

[HughP]

@RichardWallis @thadguidry https://schema.org/Manuscript has a note saying that the community is looking for feedback. I'm not sure where to put this feedback with the recent announcement that there are 1000 open issues and that new issues were looking to be restricted. My question is as follows:

Would pre-print items fit under the description of manuscript?

In the sense that in 1850, if I worked on a book manuscript it was often done in hand written form, then in the early 1900's manuscripts became something which were typewritten but not yet typeset. Now, in the academic domain manuscripts are those works which are not formally published, but may be publicly distributed like on https://arxiv.org/ (and other related sites) or personal websites. If we stick with the current definition, then it seems that a pre-print "manuscript" should have its own class... but it seems logical to expand the definition.

[RichardWallis]

I believe 'manuscript' refers to the physical form of the creative work - 'A book, document, or piece of music written by hand rather than typed or printed'.

Whereas pre-print references one of several potential states in a publication lifecycle. The property creativeWorkStatus appears to be the appropriate place to reference this, either as a text string or as a link to a DefinedTerm representing that state.

As to where to have such discussions (Issue #2573), I don't believe hijacking a closed issue is a good answer.
Maybe the public-schemaorg mailing list would be more appropriate.

[siglun]

Manuscripts require numberOfPages (or perhaps even number of folios. Manuscripts are more often than not foliated not paginated), they are written by a scribe who may or may not be identical to the author (usually not identical for medieval manuscripts) and provenance (which is basically a list of changes of owner Events).

It is a problem that "manuscripts" are as wide a genre as "printed matter" or "web page".