- From: Ross Singer <ross.singer@talis.com>
- Date: Tue, 10 Dec 2013 11:56:22 -0500
- To: Karen Coyle <kcoyle@kcoyle.net>
- Cc: "public-schemabibex@w3.org" <public-schemabibex@w3.org>
- Message-ID: <CAPJqReOvO+7DGSzXx6d1GA95iY1THCaB_f03JDL4u4unPrGW_g@mail.gmail.com>
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.htmlextremely awkward. The 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> 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>> 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> markup use case >> >> and 2) will not be possible without great complication and 3) >> 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>>>>> 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> 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> 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> >> >> >> >> >> >> 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>>> >> >> 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> 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> 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>>>> >> >> 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> >> > 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 16:56:52 UTC