Re: Issue variants

Hi Dan,  Right now, we implement variants as full issue records with a "variant_of" field that points to one specific record.  That record is referred to as the "base".  This has been causing problems due to confusion over which variant should be the base.  Sometimes it's obvious, sometimes it's arbitrary.  50/50 cover variants are an example of arbitrary- if one cover is by the regular cover artist, maybe that's the base.  Or maybe if the publisher designated one cover "A" and the other "B" then "B" should be the base.
  We're currently debating the right hierarchy to use, and how to keep the database consistent as we find new variants, particularly when a newly discovered variant should actually be considered the base.  For reasons I won't get into, right now when people need to change which variant is the base, it causes our issue URLs to be unstable, which is bad.
  I think your exampleOfWork idea makes sense, although I need to spend a little more time with it to understand how it is being used in schemas elsewhere.  This would obviously not be quite the same as using exampleOfWork to connect the record for an artist with a literal example of their art.  But it does seem flexible enough that that would be OK (in general, I really admire the flexibility I see throughout the schema work).
  The "general issue" vs "specific variant" problem could still be a problem with exampleOfWork.  The difficulty is when you want to refer to an issue *without* specifying a variant at all.  Both the current GCD implementation and the exampleOfWork approach require designating one as the base.  It may not be worth the effort to get around that difficulty- it may just be better to accept the base issue record and use the context of the query or display to determine whether to treat it as a specific variant or a generic representation of the issue.
  In practical terms, the thing I dislike about using the base as the generic issue is that now you've overloaded the unique ID.  You're pulling all of the IDs from the same database sequence, so if you're identifying just by database ID (or URI), there's no way to clarify whether you want the generic issue or the specific variant.  The ID/URI is the same.  On the other hand, splitting up general issue IDs and variant IDs within the issue would be a big shift and possibly not worth it.
thanks,-henry
      From: Dan Scott <denials@gmail.com>
 To: hha1@cornell.edu 
Cc: "public-schemabibex@w3.org" <public-schemabibex@w3.org> 
 Sent: Monday, October 5, 2015 8:50 AM
 Subject: Re: Issue variants
   
Hi Henry:

On Mon, Oct 05, 2015 at 06:59:52AM +0000, hha1@cornell.edu wrote:
> Hi folks,  Variants are an active topic of discussion within the GCD right
> now.  I see that you have a variantCover description field, which handles one
> of the most common cases.  However, there are a number of "variants" in GCD
> terminology.  Newsstand vs direct distribution.  Price variants.  Some
> publishers published versions of issues with ads and without ads.  Etc.
>
> If you want to handle more types of variants than just covers, I would
> recommend considering changing "variantCover" to "variantName" or something
> similar.  Depending on how much detail you want to get into, I can talk about
> how we're considering putting some more structure around variants, as
> collectors care a lot about some types (incentive covers) but less about others
> (newsstand vs direct).

I think each variant should be described as its own full ComicIssue, using the
standard schema:name, schema:description, etc properites. My inclination would
be to use the existing http://schema.org/exampleOfWork and
http://schema.org/workExample properties; that is, have one ComicIssue that
describes the common components, and then link to that with other ComicIssue
instances that include the properties that describe the particular variations.

To extend the existing example in http://bib.schema.org/ComicIssue and link it
to the corresponding live example at comics.org, that would look something like:

<div vocab="http://schema.org/" typeof="ComicSeries">
  <h1 property="name">TRUE BLOOD</h1>
  <div property="description">
    TRUE BLOOD chronicles the backwoods Louisiana town of Bon Temps...
  </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="hasPart" typeof="ComicIssue" id="#work">
      <link property="url" href="http://www.comics.org/issue/1115108" />
      Issue <span property="issueNumber">13</span>
      <div property="hasPart" typeof="ComicStory">
        <span property="name">HERE WE GO AGAIN PART 3: FEELING SINISTER</span>
        <div property="author" typeof="Person">Author:
          <span property="name">Michael McMillian</span>
        </div>
      </div>
    </li>
    <li property="hasPart" typeof="ComicIssue" id="#var1">
      <link property="exampleOfWork" href="#work" />
      <link property="url" href="http://www.comics.org/issue/133985" />
      Issue <span property="issueNumber">13</span> [<span property="name">Cover B</span>]
      <div property="hasPart" typeof="ComicStory">
        <span property="name">HERE WE GO AGAIN PART 3: FEELING SINISTER</span>
        <div property="author" typeof="Person">Author:
          <span property="name">Michael McMillian</span>
        </div>
      </div>
      <div property="hasPart" typeof="ComicCoverArt">
        Variant cover:
        <div property="variantCover">Picture of Jason Stackhouse</div>
        <div property="creator" typeof="Person">Cover by:
          <span property="name">Michael Gaydos</span>
        </div>
      </div>
    </li>
  </ul>
</div>



> There is also the question of how to refer to an issue in general, without
> specifying a particular variant.  We haven't actually sorted that out- it's a
> topic from the past week or two.

I think that could tie in nicely with the existing exampleOfWork / workExample
structure that schema.org offers.



  

Received on Monday, 5 October 2015 20:11:46 UTC