Re: Completing schema:article

+1 to Periodical.  I think we can get into angels and pinheads regarding
the distinctions between serials types.  I mean, eventually we might want
to apply narrower definitions, but a very simple serial class is probably
what most people would want/need to begin with, anyway.

-Ross.


On Thu, Oct 31, 2013 at 8:49 PM, Thad Guidry <thadguidry@gmail.com> wrote:

>
>
>
> 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/>
>