Re: PublicationEvent for quarterlies and other odd cases

Hi Dan,
  I was actually trying to do exactly that (work up an example) when I hit this problem.  I've been wrestling with SQL for the last few days but I will get back to this.  In the meantime, I do think that quarterly periodicals are a fairly concrete example for the date fields already, and a more manageable problem to consider.
  As for being oriented towards machines, that's actually primarily what I'm considering.  But ultimately, machines are looking at data in service to some human use case, so the data that the machines can read must be the data that is useful to humans.  In your example (after also re-reading http://schema.org/docs/gs.html#advanced_dates which makes more sense to me now than the first time through), I gather that the machine would be expected to both pick up the formal date value from the "content" attribute, but also the human-readable content within the <time></time> tags.  Is this correct?  Or are the tag contents supposed to just be treated as a comment for human readers?
  The use case here is that search input may be in the form of "Spring 2013" rather than something that could easily be converted to 2013-03.  Also, in search *output*, the human reading through the results may be expecting to see quarterly dates.
thanks,-henry


 

     From: Dan Scott <denials@gmail.com>
 To: Henry Andrews <hha1@cornell.edu>; Richard Wallis <richard.wallis@dataliberate.com> 
Cc: "public-schemabibex@w3.org" <public-schemabibex@w3.org> 
 Sent: Saturday, October 10, 2015 4:18 AM
 Subject: 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 WallisFounder, Data Liberatehttp://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