- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 10 Dec 2013 08:06:35 -0800
- To: public-schemabibex@w3.org
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