- From: Corey A Harper <corey.harper@nyu.edu>
- Date: Tue, 10 Dec 2013 12:40:26 -0500
- To: Karen Coyle <kcoyle@kcoyle.net>
- Cc: Ross Singer <ross.singer@talis.com>, "public-schemabibex@w3.org" <public-schemabibex@w3.org>
- Message-ID: <CAE4UJ7VfOh91kcphafe3vjdpCit9VEY6BGqRsSso=1sx+wHfBQ@mail.gmail.com>
Karen, et al., I'm confused by this, still. I don't understand how volume and issue can be properties of periodical. If that were the case, you'd have an identifier for a periodical, and you would say that it's volume 12, issue 3. You then have another with volume 12, issue 4? Same identifier, or do you need a new one? If the former, than you've just said issue 3 and issue 4 are the same. I think the cleaner way to describe what you're suggesting is to have a citation, and leave the periodical, issuance, issue, volume, publisher and the rest _as entities_ out of it. That's something that can easily be done, and that I would get behind. You could even have an identifier for that citation, and have representations of it that are nothing but strings all the way down, allowing another system use that same identifier for a citation that uses Dan's more complex representation. Such an approach would be less at odds with what Dan, et al, are proposing. This was the point I was trying to make on the last call: these proposals don't need to be at odds. They can be complimentary. I think we need to unpack this in a way that's less at cross-purposes. You say, " I consider the simple case the be the majority case". I --and most of the others on this thread, I think-- disagree. Perhaps the majority case in terms of number of people / systems creating markup. Likely not the majority case in number of citations represented. Many of us are trying to go at this from the perspective of large-scale, database-driven, data management systems. I feel like Dan's proposal is more appropriate for those of us who _do_ have more fully normalized data, who do have the equivalent of series authority data, who are using and developing systems like Koha; Ex Libris' Aleph, Alma, Primo; WorldCat; BlackLight, the Grand Comics Database, etc, and who will generate this markup through templates that will be applied across thousands if not hundreds of thousands of records. Why should that use-case be _forced_ to flatten that data into a series of un-typed strings? You could ask a similar question of Dan's proposal, which currently doesn't leave many options for the individual marking up the data on their Web-page without the aid of a bunch of MVC-based abstraction. I'd really like to find a way forward that supports all of these use-cases rather than have this silly back & forth calling into question one-another's use-cases. Regards, -Corey On Tue, Dec 10, 2013 at 12:17 PM, Karen Coyle <kcoyle@kcoyle.net> wrote: > 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 > > -- Corey A Harper Metadata Services Librarian New York University Libraries 20 Cooper Square, 3rd Floor New York, NY 10003-7112 212.998.2479 corey.harper@nyu.edu
Received on Tuesday, 10 December 2013 17:40:55 UTC