Re: First draft minimalist periodical/article proposal

On Mon, Dec 9, 2013 at 5:18 PM, Ross Singer <ross.singer@talis.com> wrote:
> On Mon, Dec 9, 2013 at 4:59 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>>
>> On 12/9/13, 11:36 AM, Ross Singer wrote:
>>>
>>> I can't say that I'm a fan of including issue and volume in Periodical.
>>>   Not only does it feel wrong, it seems like it's overloading Periodical
>>> with multiple meanings.
>>>
>>> I'd definitely prefer:
>>>
>>> Periodical > PeriodicalIssue > Article

Hey Ross - did you mean "Article is a subclass of Periodicalissue,
which is a subclass of Periodical"? Just trying to get clarity on
this; in my proposal, all three are direct subclasses of CreativeWork
(so that Article doesn't inherit "issn" from Periodical, for example).

>> Ross, in this scheme, where would volume go? Would it be part of issue?
>> The volume number itself is considered an important part of a citation. You
>> could, I suppose, say that the issue number is volume number + issue number,
>> but... it doesn't always work like that.
>
>
> My idea was that "volume" would be a property of "PeriodicalIssue", yeah.
> That way you could roughly generate a representation of "Volume" (as the set
> of issues) if you absolutely needed this.  I absolutely agree that volume is
> essential in the citation and needs to appear *somewhere*.

I had "volumeNumber" on PeriodicalIssue until I created the separate
PeriodicalVolume; so if we cut PeriodicalVolume out, that's where it
made the most sense to me, too.

>>> I have never really seen a compelling case for Volume (since it's kind
>>> of an abstract concept on its own), but Dan noted (off-list) that
>>> publishers will (sometimes) group on them (e.g.
>>> http://link.springer.com/journal/volumesAndIssues/11134#volume75,
>>> http://www.tandfonline.com/loi/wccq20?open=51&repitition=0#vol_51).  I'm
>>> not sure I find this a particularly compelling use case, but if somebody
>>> can make a convincing argument that people actually use "volume" as a
>>> first class citizen, I don't know that I would put up too much of a
>>> fight against it (but I'd prefer it to be optional).  I would *really*
>>> like to hear the opinion of some people in publishing on this.  I feel
>>> like we're modeling their universe without any input from them, which is
>>> strange.
>>
>>
>> I agree about volume - it seems to mainly be a convenient numbering system
>> but without representing *content* per se. Trying to think about sales, I
>> did an example with offer, but could only find (online) subscription offers,
>> not sales of issues. On the newsstand, an issue has a price, which
>> presumably is meaningful to periodical publishers (and to the comics folks).
>> The only online place where I could find offers for individual issues was
>> eBay.

The Google Play Newsstand offers back issues for sale:
https://play.google.com/store/newsstand/details/Popular_Mechanics_Magazine
(not sure if this link will show up for you across the border, but
there is a back issue section about half way down). And there are
sites like http://backissues.com/publications/New-Yorker which would
benefit from a schema.org consultant wise in the ways of Offer and
friends.

> I suppose another example where volumes may tangibly exist is in bound
> periodicals, but this seems totally edge case-y to me.  Dan mentioned a use
> case around volumes as a proxy for editorial boards, but I don't think it
> applies universally enough, personally.

Yep, although that's mostly nostalgia from my days at the student
newspaper. And realistically, that board can and does change from
issue to issue anyway.

Part of my motivation for a separate Volume class had been to support
what seemed to be a more pressing requirement on the Comics side of
things. But further discussions with Peter and Henry (ah, domain
expertise!) suggest that that was a misunderstanding on my part.

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

I've been combing through the Bibo archives and they faced the same
flat vs. relational dilemma in their past that we're agonizing over
now; evidently they chose to omit volume as a class. But their
hierarchy has Issue as a subclass of CollectedDocument, which is a
subclass of Document... so I believe issues _can_ have volume numbers
in Bibo.

>>
>>
>> Well, the one commonality is both periodicals and books can have numbered
>> volumes.
>
>
> Certainly, but I don't think they mean exactly the same thing.  It would
> require both Book and Article to descend from the same superclass, which
> might be a hard sell.

Hey, they both descend from CreativeWork! As if that needs yet another
property... A couple of other options are to have volumeNumber apply
to both Book and PeriodicalIssue via domainIncludes, or to use
multiple types (Book with an alternate type of PeriodicalIssue) to
represent monographic serials.

I'll mention this elsewhere, but given the Bibo precedent (which seems
to have been working in practice), and the emerging clarity of the
Comics requirements, I'll revert my proposal back to just a Periodical
/ PeriodicalIssue / Article structure (each a direct subclass of
CreativeWork). That will reduce the number of new has/partOf
properties, too. If we do get some publishers who make a pressing case
for volume as a separate class, or the Bibo folks indicate strong
regrets about their decisions, it wouldn't be much work at all to put
it back in.

Thanks,
Dan

Received on Tuesday, 10 December 2013 00:22:21 UTC