- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Thu, 28 Nov 2013 09:00:26 +0200
- To: <public-schemabibex@w3.org>
Hi Dan, On the collection aspect, you've definitely made me feel *really* strongly about the subclassing. That some (many) issues are collections, no doubts. But that some issues are *not* collections is enough to bar the general subclass option. And your theoretical treatment of 'atomic' issues as singleton sets, though formally elegant, is a no-go. We're here to keep things simple and intuitive, not to create solutions worth of the most complex formal ontologies. NB: I wouldn't have objection to use Collection's 'hasPart' to indicate that an issue has several components (and so that some issues are collections indeed). But it's also possible to make 'article' a sub-property' of hasPart. This would do the trick at the formal level, while keeping a property that has much 'business sense'. But of course this pattern has the disadvantage of needing (some) people (and machines) to look at the property definition. Cheers, Antoine > On Wed, Nov 27, 2013 at 11:10 AM, Karen Coyle <kcoyle@kcoyle.net> wrote: >> >> >> On 11/27/13 7:26 AM, Antoine Isaac wrote: >> >>> >>> Wow, now it seems that I am the one confused ;-) >>> I didn't mean to make any comment on periodical, just on 'issuance', >>> which to me was the same as the much more intuitive notion of 'issue'. >>> To me an issue is not a collection--and that's what is implied by the >>> "Thing > CreativeWork > Collection > Issuance" from the current proposal. >>> But maybe I've wrongly understood the proposal... >> >> >> No, I think I wrongly understood your point. I thought you were saying that >> Issuance SHOULD be sub to Collection. And I was saying that Periodical >> SHOULD NOT be sub to collection. > > On the most recent call, I was convinced that Issuance should not be > Intangible and should instead be subclassed to Collection because in > the context of an academic journal, newspaper, news journal, popular > magazine context it acts as a collection of articles, editorials, > letters to the editor, pictorial spreads, etc. > > Many of the comics that I have in my (dated) personal collection > include a foreword where the editor / writer / artists may have > something to say to the readers, that is separate from the main story. > And some (hi Groo!) also include a letters section. In a description > of the contents of a given issue, one could very conceivably want to > cite separate CreativeWorks within the issue (for example, Alan Moore > as the author of a foreword to the V for Vendetta series in issue #1). > So the subclassing of Issuance to Collection still makes sense to me. > > Even if a given issue collects just one CreativeWork, it doesn't > disturb me. (The Comics proposal includes a similar statement about a > series potentially consisting of a single one-shot issue, for what > it's worth). > > However, in reviewing the comics proposal and considering these other > kinds of CreativeWorks that might be contained in a broader sense of > Periodical, perhaps the proposed Issuance property of "article", which > has a range of Article and is described as "An article contained in > this issue" is too specific? I do like the clarity of the current > proposal for handling most magazine / journal requirements, and am > wary of trying to satisfy too generic a need, but perhaps "article" > goes away and we just rely on the Collection "hasPart" property to > point at the CreativeWorks. > > On the flip side, I've also started wondering if "Collection"'s > properties shouldn't simply be absorbed into CreativeWork. That would > resolve the problem of Books that collect individual articles, TV > episodes that contain multiple distinct stories, and probably many > other use cases. > >> So we might have been saying the same >> thing. But I agree that Issuance-sub-Collection doesn't make sense, and I'm >> not sure that Issuance should have article page numbers, because I see that >> as a property of the article itself. That said.... > > I'm standing behind "pagination" as an Issuance-level property, > because we've seen in a number of examples so far of periodicals that > have continuing paginations (e.g. issue 1 has pages 1-150, issue 2 has > pages 151-300, etc), and the journal issues as displayed by the > publisher and various discovery layers feel that it is important > enough to include the pagination in the current displays. We need > "pagination" rather than Book's "numberOfPages" because there is no > way of knowing if the pagination is continuing or not with a plain > Integer value. > > I agree that Articles can and should still have their own pagination > property. We could make it more complex than the current Text range > (something like http://schema.org/OpeningHoursSpecification?) but I'm > not sure if we really want to go there :) > >> Here's what the comics proposal lists [1]: >> >> >> Periodical Series - a sequential grouping of periodical issues - The >> New Yorker, Redbook, The Lancet, Amazing Spider-Man >> Periodical Issues - individual instances of periodicals - The New Yorker >> Vol. 1, Issue 4 >> Individual comic issues - short-form, saddle-stitched, serially >> published comics (the pamphlet-sized comics seen in comic book stores and >> hobby shops) - Amazing Spider-Man# 600 >> >> Their series includes the volume (even tho' the definition does not), so it >> looks like our issuance crosses their 'series' and 'issues'. > > Yes, I've been puzzling over that for a while, and wondering if their > use case for "grouping of periodical issues" was perhaps focused on > story arcs, or runs with the same writer (back when Alan Moore took > over Swamp Thing, for example) or artist, rather than strictly on > volume. It's an interesting one! > >> Their "Individual comic issue" seems to be an anthology of previously published >> items, most likely within a series, that might get a series statement in >> library cataloging.[2] It could be thought of as a collection, but I doubt >> if anyone will be listing the individual parts. > > My interpretation was that Comic Issue was meant to simply model a > single issue of a 32-page (or whatever) comic book that you would pick > up at a comic store. > >> They also have "Graphic >> novel" which is a monograph that extends book, but that isn't a re-print of >> things that were once part of a comic series. > > Well... they have the "collectedIssues" property which explicitly says > that it is "a list of all issues collected in the graphic novel (for > collections of reprinted works)" to support both use cases, I believe. > >> I think at this point we need a comparative table. I will try to do that. >> What I think this means, though, is that there will be different views so >> that periodicity may be used in a variety of ways at different bibliographic >> "levels." Which would mean that we need to impose little pre-conceived >> structure on properties like "issue" "volume" etc. so that people can use >> them as they exist within their own context. >> >> I don't know how we engage the comics folks on this, but it could be an >> interesting conversation. > > I've CCed Peter Olson and Henry Andrews, who were part of the > discussion on public-vocabs back in February 2012. Hopefully they are > still interested! > >> >> kc >> >> p.s. I KNEW that serials would be a headache! >> >> >> [1] http://www.w3.org/wiki/WebSchemas/PeriodicalsComics >> [2] I tried to find some examples, but libraries don't carry the flimsy >> comics, usually, and some seem to be doing funky cataloging of the ones they >> do buy, expecting that they won't last long. In any case, how libraries >> catalog comics shouldn't drive too much of our view, IMO. > > There are examples like > http://marvel.com/comics/issue/43271/wolverine_the_x-men_2011_33 - > which make me think that a property for cover art & variant cover art > would be a good addition to the comics proposal. >
Received on Thursday, 28 November 2013 07:02:28 UTC