- From: Dan Scott <denials@gmail.com>
- Date: Tue, 10 Dec 2013 09:59:28 -0500
- To: Ross Singer <ross.singer@talis.com>
- Cc: Karen Coyle <kcoyle@kcoyle.net>, "public-schemabibex@w3.org" <public-schemabibex@w3.org>
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