Aligning with Bibo types and properties (was Re: First draft minimalist periodical/article proposal)

On Mon, Dec 9, 2013 at 2:36 PM, Ross Singer <ross.singer@talis.com> wrote:

<snip>

> The main reason I would like to keep "PeriodicalIssue" (or some equivalent)
> is to be able to align with Bibliontology (http://bibliontology.com/):
> Periodical would align pretty well with
> http://neologism.ecs.soton.ac.uk/bibo#Periodical; PeriodicalIssue to
> http://neologism.ecs.soton.ac.uk/bibo#Issue; and Article to
> http://neologism.ecs.soton.ac.uk/bibo#Document or
> http://neologism.ecs.soton.ac.uk/bibo#Article (I'd probably lean towards the
> more conservative superclass, but I don't have a strong opinion either way).
>
> Bibo only puts 'volume' on Document, which says to me that it was a
> compromise between books and serials and associated it with the Article,
> rather than the Issue, which probably doesn't apply to us unless there's
> commonality between Article and Book.

Thanks for starting this, Ross!

I've been annotating the Periodical / PeriodicalIssue / Article
proposal with notes where Bibo properties and classes align.

There are a few other clear alignments for newly proposed periodical properties:

* bibo:issn for our new issn property
* bibo:issue for our new issueNumber property
* bibo:volume for our new volumeNumber property

Karen's proposal, which adds endPage and startPage, would have clear
alignments to:

* bibo:pageEnd for endPage
* bibo:pageStart for startPage

Bibo also has a "pages" property that is to be used only when the
document is not continuously numbered and thus cannot be described by
a combination of pageEnd / pageStart (for example, "1-6, 9-12, 75".
This does not quite map to our proposed "pagination" which was meant
to be a bit more free-from, but in the interest of aligning with Bibo,
I think it would make sense to adjust ours accordingly.

The challenge is that Bibo has a Document class that schema.org
currently does not. And of course, Document is the domain of many of
these properties, and also the superclass of many of the other
classes. This is where I think Karen felt the tension of wanting to
have the properties live on just one class, but didn't want that class
to be CreativeWork because, well, adding yet more document-centric
properties to a class that also includes sculptures and movies and
audio content is not elegant. (Well, actually... Bibo's Document
subclasses include AudioVisualDocument so it ends up including Film...
so maybe we align bibo:Document to schema:CreativeWork, even though
CreativeWork has an even broader scope).

So, one way of moving forward tactically would be to:

1) For now, define the properties as they correspond to Bibo, and
domainInclude them to Book, PeriodicalIssue, and Article. This would
enable publishers-on-the-web to begin publishing schema.org structured
data for periodicals in the near term. (I would amend the
Periodical/PeriodicalIssue/Article proposal to use pageEnd, pageStart,
and pageNumbers in accordance with Bibo's existing definitions and
practice).

2) In a separate (subsequent) proposal, push for a stronger alignment
with Bibo. We could either

a) introduce Document as a subclass of CreativeWork, align
Bibo:Document to schema:Document, make Book and PeriodicalIssue and
Article subclasses of Document, and hang the appropriate properties
off of Document. This would reduce the number of domainInclude
directives by shifting properties up from Book and Article and
PeriodicalIssue to the Document level.

or

b) Add the required properties to CreativeWork (hey, what's a few
more!) and align Bibo:Document to schema:CreativeWork.

In either case, all of the existing schema.org structured data will
still be valid, but the overall schema.org structure will have been
simplified and easier to map for those already familiar with Bibo. As
a bonus, if we follow Bibo's lead and hang volumeNumber off of
Document, then Book gets to use it for free :)

As examples of the many other possible alignments to the schema.org
RDFS from other Bibo classes and properties:

* bibo:cites for schema:citation
* bibo:content for schema:text
* bibo:gtin14 for schema:gtin14
* bibo:isbn for schema:isbn
* bibo:numPages for schema:numberOfPages

... well, there are many others. I think that this should be a
separate proposal because it is likely to get bogged down both in
requirements revalidation (Bibo defined X and Y, but are they actually
being used in practice) and implementation details (for example, if
subproperty relationships enter the mix). And it is more disruptive to
the existing schema.org vocabulary, so I imagine it will take more
time and discussion on public-vocabs to shepherd it through than the
tactical short-term proposal that introduces two classes and a handful
of properties. But I would be willing to put in the work required to
make this take shape.

Received on Tuesday, 10 December 2013 14:59:56 UTC