- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 10 Dec 2013 09:17:27 -0800
- To: Ross Singer <ross.singer@talis.com>
- CC: "public-schemabibex@w3.org" <public-schemabibex@w3.org>
Ross, it's SHOULD not MUST, and the header is "expected type" -- but in discussions w DanBri and others, they admit that they aren't considering other input invalid. However, I consider this digression irrelevant to what matters in this discussion. Yes, periodical volume and periodical issue are generally strings. I still think that volume and issue can be properties of Periodical in a simple scheme that works for markup of the vast majority of web pages with article information. I do NOT think that trying to replicate the complex structure of periodical publication serves the simple case, and I consider the simple case the be the majority case. This simple approach works for: RIS, BIBTEX, Endnote, Mendeley, Zotero, the PRIMO display, and others. That's my view. kc On 12/10/13, 8:56 AM, Ross Singer wrote: > I think what I'm trying to say is that I don't understand what you're > proposing the intended domains for "volume" and "issue" to be. In your > example, they're strings. I don't think this is splitting hairs to say > it would make something like > http://www.nature.com/nature/archive/index.html extremely awkward. > > The schema.org <http://schema.org> documentations says > > each property may have one or more types as its ranges. The value(s) > of the property should be instances of at least one of these types. [1] > > > That seems, to me, a little stronger than a suggestion. > > But I don't see how asking for the range of Periodical#issue/issues to > be PeriodicalIssue is fundamentally any different than how > Series/Episode is currently designed. > > -Ross. > 1. http://schema.org/docs/datamodel.html > > > On Tue, Dec 10, 2013 at 11:27 AM, Karen Coyle <kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> wrote: > > > > On 12/10/13, 3:28 AM, Ross Singer wrote: > > By "elsewhere" I mean PeriodicalIssue. > > In your Series example, the range of episode/episodes is > http://schema.org/Episode > > In your proposal, aren't these strings? > > > Yes, but as you know, ranges in schema are suggested, not required. > Really, I think a lot of hairs are being split here, given the > actual goals. > > kc > > > -Ross. > > On Dec 10, 2013 12:37 AM, "Karen Coyle" <kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> wrote: > > > > On 12/9/13, 6:33 PM, Ross Singer wrote: > > > Karen, can you extrapolate why you think it would be a > journal > property? > > It seems to me that journal hasMany volumes/issues, > which would put > these properties elsewhere. > > > Hmmm. I'm not sure what you mean by "elsewhere." The > periodical is > something that is published over time in discrete parts, > and the > serially published parts are usually in the form of volumes > (that > are usually temporal, e.g. they represent a year of > publication) and > issues (that are the serial "manifestations", numbered > subordinate > to the volume, and with a physical presence). It is a kind of > whole/part relationship. However, it is a whole/part > relationship > that has a great deal of variation, so no one pattern will > work for > periodicals in general. In other words, we've got to fudge > it somewhere. > > However, I think that your point is that the metadata has > to have > the same structure as the periodical. I'm saying that doing > so 1) is > not necessary for the schema.org <http://schema.org> > <http://schema.org> markup use case > > and 2) will not be possible without great complication and 3) > schema.org <http://schema.org> <http://schema.org>, with its > flat namespace, in any case > > will not reproduce the periodical structure without making the > periodical schema very complicated. > > I think we can do periodical in a way that is analogous to > http://schema.org/Series, which has the properties "season" and > "episode" where episode is one instance within a season > within a series. > > kc > > > > > > > -Ross. > > > > kc > > > > > >> > >> -Ross. > >> > >> > >> kc > >> > >> > >> > >> -Ross. > >> > >> > >> On Mon, Dec 9, 2013 at 1:40 PM, Karen Coyle > <kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> > >> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>> > >> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto: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> > <http://schema.org> <http://schema.org> > <http://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> > <http://schema.org> <http://schema.org> > <http://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> <http://schema.org> > <http://schema.org> > >> <http://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> > > <http://www.w3.org/community/______schemabibex/wiki/__Periodical_____Article_minimal > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal>__> > > >> > > <http://www.w3.org/community/______schemabibex/wiki/__Periodical_____Article_minimal > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal> > > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal > <http://www.w3.org/community/__schemabibex/wiki/Periodical___Article_minimal>>> > >> > >> > >> > >> > > <http://www.w3.org/community/______schemabibex/wiki/__Periodical_____Article_minimal > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal> > > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal > <http://www.w3.org/community/__schemabibex/wiki/Periodical___Article_minimal>> > >> > > <http://www.w3.org/community/____schemabibex/wiki/Periodical_____Article_minimal > <http://www.w3.org/community/__schemabibex/wiki/Periodical___Article_minimal> > > <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> <http://schema.org> > <http://schema.org> > <http://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> <http://schema.org> > <http://schema.org> > >> <http://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> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>> > >> <mailto:kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>>> > >> http://kcoyle.net > >> m: 1-510-435-8234 > <tel:1-510-435-8234> <tel:1-510-435-8234 <tel:1-510-435-8234>> > <tel:1-510-435-8234 <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>>> <tel:1-510-435-8234 > <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>> > >> > >> <tel:1-510-435-8234 <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>>>> > > >> skype: kcoylenet > >> > >> > >> > >> -- > >> Karen Coyle > >> kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>>> > http://kcoyle.net > >> m: 1-510-435-8234 <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>> > <tel:1-510-435-8234 <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>>> > >> skype: kcoylenet > >> > >> > > > > -- > > Karen Coyle > > kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> > http://kcoyle.net > > m: 1-510-435-8234 <tel:1-510-435-8234> > <tel:1-510-435-8234 <tel:1-510-435-8234>> > > skype: kcoylenet > > > -- > Karen Coyle > kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> > <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>> > http://kcoyle.net > m: 1-510-435-8234 <tel:1-510-435-8234> <tel:1-510-435-8234 > <tel:1-510-435-8234>> > skype: kcoylenet > > > -- > 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 17:17:55 UTC