Re: PublicationEvent for quarterlies and other odd cases

Henry:

To a large extent, the schema.org metadata is for machines, not people.

In this case, you could do something like <time property="datePublished"
content="2013-03">Spring 2013</time> and satisfy both the machines and the
people.

Rather than bringing up a whole bunch of concerns separately and somewhat
abstractly, can I suggest that you try building a few complete examples on
a wiki page or somewhere where others can comment and provide alternative
solutions? We've almost always had our best successes when we work with
concrete examples drawn from real life.

On Fri, Oct 9, 2015, 23:12 Henry Andrews <hha1@cornell.edu> wrote:

> Hmm... this makes datePublished sound sort of like our "key date", which
> is the sortable date that best approximates the publication date.  The
> difference being that "key date" is never shown to end users.  Indexers see
> it when they add an issue, but it's usually auto-generated from the
> publication date and only needs to be edited if there's something unusually
> strange about the publication date.
>
> When an end user is searching for a comic, they will search by "Spring
> 2013" and/or expect to see that sort of date in the results if that is how
> the publication date is printed on the comic.  They will definitely not be
> looking for "2013-03" or "March 2013".  So I am concerned about moving the
> user-oriented date to an "alternate" field.
>
> Squishing all of the random strange "dates" that publishers come up with
> into a sortable proper date field is, to me, an implementation detail of
> sorting** and not what we want to highlight.
>
> Also note that "date of publication" (whether it comes from the
> indicia/colophon or cover) is not the same as "release date", which is
> always a proper date.
>
> thanks,
> -henry
>
> **I'm glossing over a lot of subtleties with sorting- when showing the
> order of issues in a series, we do not directly rely on key date, for
> instance.
>
> ------------------------------
> *From:* Richard Wallis <richard.wallis@dataliberate.com>
> *To:* Henry Andrews <hha1@cornell.edu>
> *Cc:* "public-schemabibex@w3.org" <public-schemabibex@w3.org>
> *Sent:* Friday, October 9, 2015 8:17 AM
> *Subject:* Re: PublicationEvent for quarterlies and other odd cases
>
> I would suggest that datePublished is probably the best place to put the
> date of publication: YYYY or YYY-MM etc. (2015 or 2015-04).
>
> As to cover date, my inclination is to see that more as a name or
> alternateName, or maybe even a short description, which handle all sorts
> of variations: "The Obscure Journal - Spring 2014 Issue",  "The Obscure
> Journal: May-October 2012".  As these would be described as
> PublicationIssue(s), perhaps with an exampleOfWork link to a Periodical
> description, such names would make sense.
>
> ~Richard.
>
> Richard Wallis
> Founder, Data Liberate
> http://dataliberate.com
> Linkedin: http://www.linkedin.com/in/richardwallis
> Twitter: @rjw
>
>
>
> On 7 October 2015 at 07:09, <hha1@cornell.edu> wrote:
>
> Hi folks,
>
>   Looking at the PublicationIssue and PublicationEvent, I'm confused as to
> where to put the cover date and how to represent dates that don't map
> directly to the ISO format.  Quarterlies are the most obvious, but
> bi-monthlies and semi-monthlies are other examples.  I'm also confused as
> to whether this should be in "datePublished" (as a date) or "publication"
> (as a PublicationEvent, which could indicate a quarter by giving a
> startDate and endDate of the relevant months, perhaps?).
>
>   I don't see an example of anything other than a fully specified date- is
> there a more comprehensive set of date examples somewhere?  Defining a
> PublicationEvent that spans the whole time designated by the cover date
> seems to be the most flexible option, but perhaps that is stretching the
> concept of "Event" too far.
>
>   "releasedEvent" seems like the clear home for the actual release
> date(s), which are easier as they are full dates.
>
> thanks,
> -henry
>
>
>
>
>