- From: Ross Singer <ross.singer@talis.com>
- Date: Mon, 9 Dec 2013 17:18:40 -0500
- To: Karen Coyle <kcoyle@kcoyle.net>
- Cc: "public-schemabibex@w3.org" <public-schemabibex@w3.org>
- Message-ID: <CAPJqReNbQU_Log9M24hXLn1QN3Rvxr3of8dOZ3x5+4mRuqhYwQ@mail.gmail.com>
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 >> > > 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*. > > This is partly why I overloaded Periodical with volume and issue -- it > seems that if you break out issue, you also need to break out volume. But > of course there are periodicals with issues but not volumes, volumes but > not issues, numbering that precedes volumes... there isn't a single order > that you can count on. By leaving it flat-ish, you can put issue and volume > in whatever order they appear in your citation. The other option is to do > what MARC does and just have an n-level array -- six in the case of MARC > (!) -- that you can fit to your particular case. > Are there volumes without issues? I have never seen an example of this. Wouldn't that just be an issue under another name? I guess I would think of "issue" as any "release" from the periodical. > > 1) Acta Biologica blah blah 2) Part A 3) Volume x 4) Issue y > 1) Acta Biologica blah blah 2) Part B 3) Volume x 4) Issue y > 1) Acta Biologica blah blah 2) Yearly Supplement > 1) Acta Biologica blah blah 2) Part B 3) Yearly index to Part B > > I assume we don't want to go there, but if we allow there to be at least > two levels of numbering, without a fixed order, then we aren't trying to > force everything into a structure that may not fit the case. Definitely don't want to go there :) > > > > >> 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. 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. > > > > >> 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. >> > > 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. If we absolutely must boil this down to two classes: Periodical and Article, I would prefer volume and issue to be on Article, rather than Periodical, but in my mind, the three classes (Periodical, Issue, Article) fits the best balance of accurate description and lack of horrible complexity. That said, a citation is still going to be a jumble. I still would like to get a journal person's take. Tony Hammond? Alf Eaton? Isn't he on this list? Others? I don't know many people at the publishers. -Ross. > > kc > > > >> -Ross. >> >> >> On Mon, Dec 9, 2013 at 1:40 PM, Karen Coyle <kcoyle@kcoyle.net >> <mailto:kcoyle@kcoyle.net>> wrote: >> >> >> >> On 12/9/13, 9:45 AM, Dan Scott wrote: >> >> >> Properties that obviously cross different classes, IMO, need >> a general home. >> Someone marking up book chapters may not think to look in >> Periodical or >> Article for pagination patterns. (I've talked with DanBri >> about this, but >> schema desperately needs a good visualization that is >> graph-oriented, not >> hierarchical.) >> >> >> I think the mechanism is to simply add a domainIncludes >> declaration >> for each property of interest pointing at the type (for example, >> BookChapter, if it gets defined).. >> >> >> Which one could have done with MedicalArticle in order to make use >> of citation. So either one takes the view that you only need >> domainIncludes, or that the structure matters, not sometimes one >> way, some times the other. >> >> Honestly, I think that schema.org <http://schema.org> itself hasn't >> >> made this decision -- which is why we end up looking at it in both >> ways. Since "the mechanism is simply to add a domainIncludes >> declaration..." as a technical solution, I like to look at what will >> help people using schema.org <http://schema.org> as a strong >> >> motivator for decisions. It's still a crap shoot, I admit. >> >> >> >> I'll admit to being surprised at the idea of adding a Pagination >> class; that seems like a much less useful thing to potentially >> link to >> than an individual issue. And there is no complexity in the pages >> / >> startPage / endPage properties that binds their relationship >> (vs. say >> a Contributor class that would let one encode or encapsulate the >> nature of the contribution, rather than requiring every possible >> type >> of contributor to become its own property). >> >> >> I don't know what you mean by "every possible type of contributor to >> become its own property" but the reason that I have for moving >> pagination out of periodical is that it is also useful for book/book >> chapter, unless you expect people to domainIncludes Book to >> Periodical. That, I think, would not occur to many people. >> >> >> >> FWIW, I originally wanted to name the "pagination" property >> "pages" or >> "pageNumbers", but balked because schema.org <http://schema.org> >> >> has deprecated most of >> the plural attribute names in favour of the singular. That said, >> in my >> research last week checking the MLA and APA style manuals, "page >> numbers" was the most commonly used term between the two, >> followed by >> "pagination". So I would suggest either "pageNumbers" or >> "pagination". >> This would avoid any possible terminology conflict with "page(s)" >> as >> in the assistants to members of parliament, or (heh) >> people-typically-teenagers who shelve books at libraries. >> >> >> Both pageNumbers and pagination sound fine. >> >> >> >> >> But given that you want Periodical to be a subclass of >> Series, >> shouldn't that line reflect that deeper nesting and >> actually look like >> the following? >> >> Thing > CreativeWork > Series > Periodical > Article >> >> >> >> I have no idea what Series means in relation to Periodical, >> and hadn't >> included it in my proposal. >> >> >> http://www.w3.org/community/__schemabibex/wiki/Periodical___ >> Article_minimal >> >> <http://www.w3.org/community/schemabibex/wiki/Periodical_ >> Article_minimal> >> is the right page for me to be looking at, right? If so, there's a >> section at the top that says: >> >> """ >> Subclass Periodical to Series >> >> Thing > CreativeWork > Series >> >> Periodical will also need to be sub-classed to Series to make >> use of... >> """ >> >> This is why I thought you want Periodical to be a sublass of >> Series. >> >> >> Ah, yes. I'd forgotten that the start and end dates were in Series. >> I also suggest further down in the Intangible area that perhaps >> those should be moved to Intangible since that was one of those >> opportunistic subclassings that I find so illogical. So it again >> brings up the question of whether there is any logic to schema.org >> <http://schema.org> or if one simply wants to subclass promiscuously >> >> to get whatever properties one needs. I can go with either some >> semblance of logical arrangement or treating schema.org >> <http://schema.org> as a flat vocabulary (and doing a lot of >> >> opportunistic subclassing) but being on the pendulum between them >> gives me whiplash. I think this is a problem that many are having >> with schema, and unfortunately I don't see it getting cleared up any >> time soon. We should probably just decide what our goals are and not >> worry too much about the whole. (I think this is what the medical >> folks did.) >> >> kc >> >> >> >> I see them as bibliographically distinct, for >> reasons that I articulated to Antoine a while back. Although >> series and >> periodical share the use of volume numbers, I wouldn't >> consider a periodical >> a type of series, for my bibliographic concept of series. >> >> >> Okay. >> >> If, as you say >> above, the structure in schema isn't significant, then this >> deeper nesting, >> IMO, isn't necessary, and yet sends the message that the >> structure IS >> significant. This, again, is a contradiction within schema >> that encourages >> structure yet ignores it. >> >> >> I don't think I said, and did not mean to imply in any way, that >> the >> structure in schema is not significant. I was just trying to >> point out >> the domainIncludes approach to go along with the subclass option. >> >> Thanks, >> Dan >> >> >> -- >> Karen Coyle >> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net >> m: 1-510-435-8234 <tel:1-510-435-8234> >> skype: kcoylenet >> >> >> > -- > Karen Coyle > kcoyle@kcoyle.net http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet >
Received on Monday, 9 December 2013 22:19:10 UTC