Re: First draft minimalist periodical/article proposal

I, too, like that idea. They have solved many of the problems we've 
brought up by having

1) a "document" class to which monographs, periodicals, and articles can 
be sub-

2) a property that represents a stylized citation, like those used for 
articles:

Property: bibo:locator

locator – A description (often numeric) that locates an item within a 
containing document or collection.

URI:
     http://purl.org/ontology/bibo/locator
Domain:
     bibo:Document
Range:
     rdfs:Literal
Subproperties:
     bibo:chapter, bibo:issue, bibo:pageEnd, bibo:pageStart, bibo:pages, 
bibo:section, bibo:volume

In this, proposer, volumes, issues, chapters, pages, etc. are all 
subproperties. This makes creating markup of a citation easier than 
trying to make the citation use a hierarchical structure describes the 
top-down relationship between periodicals or books and their parts.

kc

On 12/10/13, 1:02 AM, Shlomo Sanders wrote:
> +1 on being able to align with http://bibliontology.com/
>
> Thanks,
> Shlomo
>
> Sent from my iPad
>
> On Dec 9, 2013, at 21:37, "Ross Singer" <ross.singer@talis.com
> <mailto:ross.singer@talis.com>> wrote:
>
>> I can't say that I'm a fan of including issue and volume in
>> Periodical.  Not only does it feel wrong, it seems like it's
>> overloading Periodical with multiple meanings.
>>
>> I'd definitely prefer:
>>
>> Periodical > PeriodicalIssue > Article
>>
>> I have never really seen a compelling case for Volume (since it's kind
>> of an abstract concept on its own), but Dan noted (off-list) that
>> publishers will (sometimes) group on them (e.g.
>> http://link.springer.com/journal/volumesAndIssues/11134#volume75,
>> http://www.tandfonline.com/loi/wccq20?open=51&repitition=0#vol_51).
>>  I'm not sure I find this a particularly compelling use case, but if
>> somebody can make a convincing argument that people actually use
>> "volume" as a first class citizen, I don't know that I would put up
>> too much of a fight against it (but I'd prefer it to be optional).  I
>> would *really* like to hear the opinion of some people in publishing
>> on this.  I feel like we're modeling their universe without any input
>> from them, which is strange.
>>
>> The main reason I would like to keep "PeriodicalIssue" (or some
>> equivalent) is to be able to align with Bibliontology
>> (http://bibliontology.com/):  Periodical would align pretty well with
>> http://neologism.ecs.soton.ac.uk/bibo#Periodical; PeriodicalIssue to
>> http://neologism.ecs.soton.ac.uk/bibo#Issue; and Article to
>> http://neologism.ecs.soton.ac.uk/bibo#Document or
>> http://neologism.ecs.soton.ac.uk/bibo#Article (I'd probably lean
>> towards the more conservative superclass, but I don't have a strong
>> opinion either way).
>>
>> Bibo only puts 'volume' on Document, which says to me that it was a
>> compromise between books and serials and associated it with the
>> Article, rather than the Issue, which probably doesn't apply to us
>> unless there's commonality between Article and Book.
>>
>> -Ross.
>>
>>
>> On Mon, Dec 9, 2013 at 1:40 PM, Karen Coyle <kcoyle@kcoyle.net
>> <mailto:kcoyle@kcoyle.net>> wrote:
>>
>>
>>
>>     On 12/9/13, 9:45 AM, Dan Scott wrote:
>>
>>
>>             Properties that obviously cross different classes, IMO,
>>             need a general home.
>>             Someone marking up book chapters may not think to look in
>>             Periodical or
>>             Article for pagination patterns. (I've talked with DanBri
>>             about this, but
>>             schema desperately needs a good visualization that is
>>             graph-oriented, not
>>             hierarchical.)
>>
>>
>>         I think the mechanism is to simply add a domainIncludes
>>         declaration
>>         for each property of interest pointing at the type (for example,
>>         BookChapter, if it gets defined)..
>>
>>
>>     Which one could have done with MedicalArticle in order to make use
>>     of citation. So either one takes the view that you only need
>>     domainIncludes, or that the structure matters, not sometimes one
>>     way, some times the other.
>>
>>     Honestly, I think that schema.org <http://schema.org> itself
>>     hasn't made this decision -- which is why we end up looking at it
>>     in both ways. Since "the mechanism is simply to add a
>>     domainIncludes declaration..." as a technical solution, I like to
>>     look at what will help people using schema.org <http://schema.org>
>>     as a strong motivator for decisions. It's still a crap shoot, I
>>     admit.
>>
>>
>>
>>         I'll admit to being surprised at the idea of adding a Pagination
>>         class; that seems like a much less useful thing to potentially
>>         link to
>>         than an individual issue. And there is no complexity in the
>>         pages /
>>         startPage / endPage properties that binds their relationship
>>         (vs. say
>>         a Contributor class that would let one encode or encapsulate the
>>         nature of the contribution, rather than requiring every
>>         possible type
>>         of contributor to become its own property).
>>
>>
>>     I don't know what you mean by "every possible type of contributor
>>     to become its own property" but the reason that I have for moving
>>     pagination out of periodical is that it is also useful for
>>     book/book chapter, unless you expect people to domainIncludes Book
>>     to Periodical. That, I think, would not occur to many people.
>>
>>
>>
>>         FWIW, I originally wanted to name the "pagination" property
>>         "pages" or
>>         "pageNumbers", but balked because schema.org
>>         <http://schema.org> has deprecated most of
>>         the plural attribute names in favour of the singular. That
>>         said, in my
>>         research last week checking the MLA and APA style manuals, "page
>>         numbers" was the most commonly used term between the two,
>>         followed by
>>         "pagination". So I would suggest either "pageNumbers" or
>>         "pagination".
>>         This would avoid any possible terminology conflict with
>>         "page(s)" as
>>         in the assistants to members of parliament, or (heh)
>>         people-typically-teenagers who shelve books at libraries.
>>
>>
>>     Both pageNumbers and pagination sound fine.
>>
>>
>>
>>
>>                 But given that you want Periodical to be a subclass of
>>                 Series,
>>                 shouldn't that line reflect that deeper nesting and
>>                 actually look like
>>                 the following?
>>
>>                 Thing > CreativeWork > Series > Periodical > Article
>>
>>
>>
>>             I have no idea what Series means in relation to
>>             Periodical, and hadn't
>>             included it in my proposal.
>>
>>
>>         http://www.w3.org/community/__schemabibex/wiki/Periodical___Article_minimal
>>         <http://www.w3.org/community/schemabibex/wiki/Periodical_Article_minimal>
>>         is the right page for me to be looking at, right? If so, there's a
>>         section at the top that says:
>>
>>         """
>>         Subclass Periodical to Series
>>
>>         Thing > CreativeWork > Series
>>
>>         Periodical will also need to be sub-classed to Series to make
>>         use of...
>>         """
>>
>>         This is why I thought you want Periodical to be a sublass of
>>         Series.
>>
>>
>>     Ah, yes. I'd forgotten that the start and end dates were in
>>     Series. I also suggest further down in the Intangible area that
>>     perhaps those should be moved to Intangible since that was one of
>>     those opportunistic subclassings that I find so illogical. So it
>>     again brings up the question of whether there is any logic to
>>     schema.org <http://schema.org> or if one simply wants to subclass
>>     promiscuously to get whatever properties one needs. I can go with
>>     either some semblance of logical arrangement or treating
>>     schema.org <http://schema.org> as a flat vocabulary (and doing a
>>     lot of opportunistic subclassing) but being on the pendulum
>>     between them gives me whiplash. I think this is a problem that
>>     many are having with schema, and unfortunately I don't see it
>>     getting cleared up any time soon. We should probably just decide
>>     what our goals are and not worry too much about the whole. (I
>>     think this is what the medical folks did.)
>>
>>     kc
>>
>>
>>
>>             I see them as bibliographically distinct, for
>>             reasons that I articulated to Antoine a while back.
>>             Although series and
>>             periodical share the use of volume numbers, I wouldn't
>>             consider a periodical
>>             a type of series, for my bibliographic concept of series.
>>
>>
>>         Okay.
>>
>>             If, as you say
>>             above, the structure in schema isn't significant, then
>>             this deeper nesting,
>>             IMO, isn't necessary, and yet sends the message that the
>>             structure IS
>>             significant. This, again, is a contradiction within schema
>>             that encourages
>>             structure yet ignores it.
>>
>>
>>         I don't think I said, and did not mean to imply in any way,
>>         that the
>>         structure in schema is not significant. I was just trying to
>>         point out
>>         the domainIncludes approach to go along with the subclass option.
>>
>>         Thanks,
>>         Dan
>>
>>
>>     --
>>     Karen Coyle
>>     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>>     m: 1-510-435-8234 <tel:1-510-435-8234>
>>     skype: kcoylenet
>>
>>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet

Received on Tuesday, 10 December 2013 16:07:03 UTC