Re: journal article for next call?

I see two competing views here that we somehow need to reconcile.

#1 is the view of the publisher who produces a serial publication, of 
which the issue is a stand-alone product. Dan's proposal seems to be 
focused here, as is the comics proposal.

#2 is the view of the reader/researcher/academic for whom an article is 
a primary work whose existence in a particular issue is incidental, and 
to whom the entire issue, with some rare exceptions, is not meaningful, 
and the journal volume/number/pagination information is significant 
mainly as identification/location.

I think the proof is in marking up examples to see what works. I could 
create marked-up examples but they would look very different from Dan's 
proposal, which seems to have gained acceptance from the group. In any 
case, I think that use cases are needed to test a variety of approaches. 
To save time, I suggest that use cases could be done in pseudo-code, as 
long as the results accurately reflect the proposal(s).

// warning: long set of examples follows here

// more examples at http://kcoyle.net/articles/

Here are some cases that illustrate the two views:

#1

// full page: http://www.tandfonline.com/toc/wccq20/current

Volume 51, Issue 8, 2013
Cataloging and Classification Quarterly

// followed by list of articles - one example:
The Road to BIBFRAME: The Evolution of the Idea of Bibliographic 
Transition into a Post-MARC Future
Angela Kroeger
pages 873-890
Access options

     DOI:10.1080/01639374.2013.823584
     Published online: 05 Sep 2013
     Citations: 0
     Article Views: 482

#2

// as search results; how these look in different systems
// varies quite a bit, but generally has the same
// info

1.
A coral bleaching model. Peter L. Antonelli, Solange F. Rutz, Paul W. 
Sammarco, and Kevin B. Strychar. Nonlinear Analysis: Real World 
Applications. 16 (Apr. 2014) p65. Word Count: 117.

     Abstract

Article
2.
Optimization of Electric Power Leveling Systems by Taper-Off-Reflectance 
Particle Swarm Optimization. Yohei Makino, Toshinori Fujii, Jun Imai, 
and Shigeyuki Funabiki. Electrical Engineering in Japan. 186.3 (Feb. 
2014) p10. Word Count: 198.

     Abstract

Article
3.
An integrated optimization modeling approach for planning emission 
trading and clean-energy development under uncertainty. Y.P. Li, G.H. 
Huang, and M.W. Li. Renewable Energy. 62 (Feb. 2014) p31. Word Count: 297.

     Abstract

// individual article display

  Title: Social vulnerability indicators as a sustainable planning tool
Author(s): Yung-Jaan Lee
Source: Environmental Impact Assessment Review. 44 (Jan. 2014): p31.
Document Type: Article
DOI: http://dx.doi.org/10.1016/j.eiar.2013.08.002
Abstract:

To link to full-text access for this article, visit this link: 
http://dx.doi.org/10.1016/j.eiar.2013.08.002

Byline: Yung-Jaan Lee

Abstract:

In the face of global warming and environmental change, the conventional 
strategy of resource centralization will not be able to cope with a 
future of increasingly extreme climate events and related disasters. It 
may even contribute to inter-regional disparities as a result of these 
events. To promote sustainable development, this study offers a case 
study of developmental planning in Chiayi, Taiwan and a review of the 
relevant literature to propose a framework of social vulnerability 
indicators at the township level. ...

// articles as cited or included in a bibliography, same
// article, different formats

APA:
Neyman, A. (January 01, 1999). Cooperation in Repeated Games When the 
Number of Stages is not Commonly Known. Econometrica, 67, 1, 45-64.

Chicago:
Neyman, Abraham. 1999. "Cooperation in Repeated Games When the Number of 
Stages is not Commonly Known". Econometrica. 67 (1): 45-64.

Harvard:
NEYMAN, A. (1999). Cooperation in Repeated Games When the Number of 
Stages is not Commonly Known. Econometrica. 67, 45-64.

MLA:
Neyman, Abraham. "Cooperation in Repeated Games When the Number of 
Stages Is Not Commonly Known." Econometrica. 67.1 (1999): 45-64. Print.

Turabian:
Neyman, Abraham. 1999. "Cooperation in Repeated Games When the Number of 
Stages Is Not Commonly Known". Econometrica. 67, no. 1: 45-64.

kc


On 11/28/13 7:39 AM, Dan Scott wrote:
> Hi Antoine,
>
> On Thu, Nov 28, 2013 at 2:00 AM, Antoine Isaac <aisaac@few.vu.nl> wrote:
>> 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.
>
> Hmm. At what point does the some / many / most rule tip back in favour
> of issue-as-collection?
>
>> 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.
>
> I worry that the alternative that I think you proposed is in some ways
> more complex... if I understand correctly, by "let data publishers use
> an extra type assertion to Collection (and statements with the
> "article" property) to indicate when an issuance is a composite item",
> you were recommending that we use http://schema.org/alternativeType to
> point at Collection (or the RDFa native equivalent)?
>
> So to pull from the existing example of Issuance in the Periodical
> proposal, instead of the current:
>
>     <ul>
>       <li property="issuance" typeof="Issuance">Volume <span
> property="issueVolume">7</span>,
>         issue <span property="issueNumber">6</span>
>         <span property="datePublished">2007</span>
>         pages <span property="pagination">543-633</span>
>         <ul>
>           <li property="article" typeof="ScholarlyArticle">
>             <strong property="name"><span
> property="articleSection">Opinion</span>:Trusting double-blind
> peer-review</strong>,
>             by <span property="author">Foo Bar</span>, p. <span
> property="pagination">543-545</span>
>           </li>
>           <li> ... </li>
>         </ul>
>       </li>
>
> the markup would add the Collection type to the Issuance level, like
> so: (RDFa Lite)
>
>     <ul>
>       <li property="issuance" typeof="Issuance Collection">Volume <span
> property="issueVolume">7</span>,
>         issue <span property="issueNumber">6</span>
>         <span property="datePublished">2007</span>
>         pages <span property="pagination">543-633</span>
>         <ul>
>           <li property="article" typeof="ScholarlyArticle">
>             <strong property="name"><span
> property="articleSection">Opinion</span>:Trusting double-blind
> peer-review</strong>,
>             by <span property="author">Foo Bar</span>, p. <span
> property="pagination">543-545</span>
>           </li>
>           <li> ... </li>
>         </ul>
>       </li>
>
> or in microdata via the alternativeType property:
>
>     <ul>
>       <li itemprop="issuance" itemscope itemtype="Issuance">Volume
> <span itemprop="issueVolume">7</span>,
>         issue <span itemprop="issueNumber">6</span>
>         <span itemprop="datePublished">2007</span>
>         pages <span itemprop="pagination">543-633</span>
>         <meta property="alternativeType" content="Collection">
>         <ul>
>           <li itemprop="article" itemscope itemtype="ScholarlyArticle">
>             <strong itemprop="name"><span
> itemprop="articleSection">Opinion</span>:Trusting double-blind
> peer-review</strong>,
>             by <span itemprop="author">Foo Bar</span>, p. <span
> itemprop="pagination">543-545</span>
>           </li>
>           <li> ... </li>
>         </ul>
>       </li>
>
> My concern on the complexity front is that the public-vocabs list has
> seen some posts by people confused by the concept of applying multiple
> types to a single entity, particularly in microdata. [1] [2] The
> complexity of the multiple type approach seemed to generate resistance
> on this list to the Holdings-as-Offers proposal on that front, even
> though that was the intended design of Offer. Therefore I was wary of
> stepping into those (hot) waters again.
>
> In any case, I suppose we need to mark up what the current proposal
> would look like for an Issuance that is not a collection, whether or
> not Issuance itself is a subclass of Collection. The simplest approach
> would probably be to use the existing CreativeWork properties directly
> at the Issuance level. So, taking a recent comic book issue as an
> example (I borrowed this issue from my spouse's collection for item in
> hand cataloguing purposes) and trying to reflect how a comic book
> would look if ComicIssue was a subclass of Issuance:
>
> <div vocab="http://schema.org/" typeof="Periodical"><span
> property="name">TRUE BLOOD</span>
> <div property="about">TRUE BLOOD chronicles the backwoods Louisiana
> town of Bon Temps... in a world where vampires have emerged from the
> coffin and no longer need humans for their fix.</div>
> <div property="publisher" typeof="Organization">Publisher: <span
> property="name">IDW</span> (<a property="url"
> href="http://www.idwpublishing.com">http://www.idwpublishing.com</a>)</div>
> <ul>
>    <li property="issuance" typeof="ComicIssue">Issue <span
> property="issueNumber">13</span>
>      <div property="author" typeof="Person">Author: <span
> property="name">Michael McMillian</span></div>
>      <div property="artist" typeof="Person">Art by: <span
> property="name">Beni Lobel</span></div>
>      <div property="colorist" typeof="Person">Colors by: <span
> property="name">Esther Sanz</span></div>
>      <div property="coverArtist" typeof="Person">Cover by: <span
> property="name">Michael Gaydos</span></div>
>      <div property="letterer" typeof="Person">Letters by: <span
> property="name">Neil Uyetake</span></div>
>      <div property="editor" typeof="Person">Edits by: <span
> property="name">Beni Lobel</span></div>
>      <div>Date published: <meta property="datePublished"
> content="2013-05">May 2013</div>
>    </li>
> </ul>
> </div>
>
> I'll add this to the proposal as another example, with a note that
> ComicIssue and several of its properties come from the Comics
> proposal.
>
> Aside: this version of the issue has cover "B"; there is also a cover
> "A" version of the issue. While this is common in the domain of comics
> as a way to drive up sales to collectors who simply must have all the
> variants (heh), it is not limited to comics; records, books, and
> popular magazines take this tack as well. [3] notes a magazine issue
> that has 45 different covers (that thread has some interesting
> thoughts about how to track these variations and why one might want to
> provide a way to keep them separated; sadly while 45worlds seems to be
> collecting a lot of data it does not (yet) publish it as structured
> data, but maybe if we nail the Periodical proposal down it will be
> easy for them to add it in...)
>
> Perhaps CreativeWork therefore gets a "cover" property with a range of
> ImageObject that can be repeated; the ImageObject's "name" property
> would then enable the repeated variants to be distinguished?
>
>> 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.
>
> Right, I'm in favour of "article" as a subproperty of "hasPart", this
> would be consistent with having made "partOfIssuance" and
> "partOfPeriodical" subproperties of "hasPart" as well, so I'll make
> that change now. (Checking the Periodical proposal, I will call those
> out as "subPropertyOf" rather than "subClassOf" to be RDFS-compliant).
> I don't see any downside to this.
>
> 1. http://lists.w3.org/Archives/Public/public-vocabs/2013Aug/0004.html
> 2. http://lists.w3.org/Archives/Public/public-vocabs/2013Oct/0091.html
> 3. http://www.45worlds.com/topic/100062
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet

Received on Thursday, 28 November 2013 16:25:32 UTC