- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Tue, 10 Dec 2013 08:27:26 -0800
- To: Ross Singer <ross.singer@talis.com>
- CC: public-schemabibex@w3.org
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:27:53 UTC