- From: Ross Singer <ross.singer@talis.com>
- Date: Tue, 10 Dec 2013 06:28:38 -0500
- To: Karen Coyle <kcoyle@kcoyle.net>
- Cc: public-schemabibex@w3.org
- Message-ID: <CAPJqReP85tfX6PtnS3qgSmoAot4ZrWpQUBion2oCZijLW5FRPQ@mail.gmail.com>
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? -Ross. On Dec 10, 2013 12:37 AM, "Karen Coyle" <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 markup use case and 2) will not be possible without > great complication and 3) 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>>>> 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> 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> 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> >> >> >> >> >> >> 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 >> >> >> >> 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> 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> 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>>> >> >> 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 >> > skype: kcoylenet >> >> > -- > Karen Coyle > kcoyle@kcoyle.net http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet >
Received on Tuesday, 10 December 2013 11:29:08 UTC