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

A big +1 (of course) from me for aligning our proposal(s) with existing,
well-known vocabularies, such as BIBO (and DC...). :)

Picking out a minimal subset of usable parts and, using owl:equivalentClass
and owl:equivalentProperty, define resulting schema.org terms is quite
valuable. I like where this is going.

(Also, ideally, any new additions we invent could be added to e.g. BIBO in
turn. For instance, the generalization/specialization pattern, if we manage
to stabilize it. (I have an inkling it may solve a plethora of issues
around "abstraction levels" like WEMI, which I believe are too rigid and
dichotomizing. BIBO has steered clear of WEMI so far, and although I was
happy to just use e.g. dc:isFormatOf, it may be more comprehensible to
define a less skewed generalization relation. But I digress..))

Cheers,
Niklas


On Tue, Dec 10, 2013 at 3:59 PM, Dan Scott <denials@gmail.com> wrote:

> 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.
>
>