Re: Completing schema:article

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

> Thad and Dan -
>
>
> On 10/31/13 11:14 AM, Thad Guidry wrote:
>
>> Dan is correct.
>>
>> You will need to create both a Magazine and a Journal type among others.
>>   Just like we have in Freebase already
>>
>
>
> I'm always uneasy about the split between "magazine" and "journal". Plus
> "periodical" covers both (as well as newspapers, newsletters, etc.). The
> academic world always insists on the term "scholarly article" to
> distinguish these from commercial publications and magazines. However,
> there are databases that index both types of publications and do not
> distinguish between them -- they all have a title, an ISSN, dates and/or
> numbering, with articles with authors, titles, page numbers. We should
> think about the case when it isn't possible to distinguish between types of
> periodical publications when marking up data algorithmically. Plus, I've
> never been in a discussion where we could all agree on where to draw the
> line between journals and magazines. The extremes are easy - Vogue vs. Acta
> Metallurgica. But then you always have Science Magazine. Magazine, or
> Journal? How important is it to decide when marking up the data? What is
> the use case that would guide such a decision?
>
> Note that under schema:CreativeWork there is already schema:Article with
> sub-types:
>
> newsArticle
> ScholarlyArticle
> TechArticle
>
>
(as I hand out Halloween candy...lolol)

I am uneasy as well...and so was our schema modeling in Freebase, that's
why we created so many useful types...now over 3,000, I think.

Did you read the description of the Periodical type in Freebase (along the
top) ?  http://www.freebase.com/book/periodical?schema=&lang=en

 "A periodical is a written work or collection of written works that is
typically published on a regular schedule. This includes magazines,
newspapers, journals, fanzines, zines, school newspapers, etc. This type
holds all the properties common across all types of periodicals. If there
is another type within Freebase that is more specific to the topic (for
example magazines and newspapers), all applicable types should be used.
Comic books, though often published on a regular schedule, have their own
type and are specifically NOT periodicals. For more information, please see
the Freebase wiki page on Periodical."

... so we agree.



>
>
>>     Rather than adding these to Article, perhaps we need to link to a new
>>     "schema:Magazine" (or Journal, or Periodical, or Serial, as we go
>>     deeper down the bibliographic well and try to support newspapers and
>>     comics that don't seem like a clean conceptual fit with the term
>>     "Magazine")
>>
>
>
> Again, newspapers and scholarly articles are already in schema, but not in
> a very useful way. "Magazine", IMO, is not definable. Also, the comics
> folks are already working on their own schema:
>
> http://www.w3.org/wiki/**WebSchemas/PeriodicalsComics<http://www.w3.org/wiki/WebSchemas/PeriodicalsComics>
>
>
Yeap they are... and guided initially by some suggestions from me.  Not
sure where Peter (from Marvel) is on progression of that recently
however...it's like it died or something.

They seem to be primarily interested in the issue (which is what is on the
> newsstand). I believe that what libraries will care most about in terms of
> user services is individual articles. (Internally of course they track
> issues, but I consider that function to be out of scope.) Because special
> issues are sometimes noted in the databases that libraries subscribe to, it
> should be possible to include those. However, that begs the question of
> whether there is a title for the special issue (not uncommon), and where to
> put that. (I'd have to look at some databases and see what they do with
> those -- anyone have some handy?)
>
>
>
> 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).
>
> 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.
>
> 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.)
>
> It shouldn't be hard to test this against some real displays. This will
> mean making modifications to the subclassing of the current article and its
> subclasses.
>
> kc
>
>
I was thinking that your need was the Periodical wrapper first and then all
of those other sub-types that have some Periodicity to their issuance would
be under that Periodical.  You do know that you do not have to be
absolutely explicit with schema.org types, right ? ... you can just start
and define the basic types you really need...pulling in properties from any
of the included parent types as needed.


-- 
-Thad
+ThadGuidry <https://www.google.com/+ThadGuidry>
Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>