Fwd: Completing schema:article

Once again I foiled myself by not hitting "reply all". Please see my
response to Karen, below. Apologies :/


---------- Forwarded message ----------
From: Dan Scott <denials@gmail.com>
Date: Fri, Nov 1, 2013 at 8:04 AM
Subject: Re: Completing schema:article
To: Karen Coyle <kcoyle@kcoyle.net>


On Thu, Oct 31, 2013 at 2:07 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:

<snip suggesting the addition of something like
Magazine/Periodical/Journal/Serial>

> that descends from CreativeWork with the addition of:
>>
>>
>>     * name (no need for journalTitle any more)
>>     * ISSN
>>     * issuance (or issueIdentifier or something) -> schema.org:Issue which
>>     in turn contains
>>     ** issueVolume
>>     ** issueNumber
>>     ** ... do we also need one or more properties to capture those
>>     enumerations and chronologies that rely on Season / Year rather than
>>     volumes and numbers?
>
>
>
> 1) publicationDate exists in schema:CreativeWork, so that could hold the
> season, year, and other myriad ways that periodicals count their issues
> (including combinations of the above).

The range of http://schema.org/datePublished is
http://schema.org/Date, which is an ISO 8601 date; "2013-11-01" or
"2013-W40" or the like.

> I realize that some (many?) publication patterns are more complex than that,
> but somehow we've managed with these few in most systems for a good long
> time, and most people seem to have some understanding of what they mean. I
> don't think we can take it one more level without creating great confusion.
>
> 2) I don't see a particular need for the intervening "issuance" level. Date,
> volume and number should do it.

I think that is and should be distinct from the purpose of an issue
identifier which is more likely to be used in a citation. So if we go
ahead and define schema:Issue, it could normally contain an
issueVolume and issueNumber, but optionally could fall back to plain
text (or schema:name?) like "Summer 2014" if we don't feel the need to
provide an additional catch-all property.

> 3) are you thinking that this the idea?
>
> <periodical (or some such term)
> <scholarlyArticle>
>    <author>
>    <name>
>    <Journal>
>       <name>
>       <issn>
>       <publishedDate>
>       <volume>
>       <number>
>    <pages>
>
> Or would the outer wrapper be the journal (or whatever we call it), with the
> article within that? (That makes sense to me, but is generally the opposite
> of citation formats and displays.)

There are at least two different use cases. One use case is "here's
everything we know about <Time magazine> or <Laurentian University
student newspaper>", listing all of the issues and articles contained
in those issues and linking to the articles where feasible. I can
imagine search engines and discovery layers greedily gobbling that up.

And then the second use case is the citation. As the range of
schema:citation is Text or CreativeWork, in the case that someone can
generate structured data for their citations, yes, your example would
be realistic (although thanks to the twistiness of different citation
formats, there may be a heck of a lot of references to various item
IDs from individual properties in play - or better, perhaps, an
embedded JSON-LD object that takes a cleaner structured approach and
avoids the MLA vs APA vs every other kind of citation format war).

And yes, I'm very much in favour of real markup examples! I do try to
sketch things out and look up the existing schema types and properties
before making any suggestions because I don't want to bombard the list
with half-formed thoughts. I've been reluctant to post examples to the
list every time, though, because long emails can be overwhelming.

Received on Friday, 1 November 2013 15:44:50 UTC