- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Sun, 08 Dec 2013 20:07:07 -0800
- To: Niklas Lindström <lindstream@gmail.com>
- CC: "public-schemabibex@w3.org" <public-schemabibex@w3.org>
On 12/8/13, 3:34 PM, Niklas Lindström wrote: > Karen, Jeff, > > > In any case, we need a "part of" relation between the article and the > periodical. Jeff's concern is probably well-founded, but I'm not sure what we can do. Schema, as Martin Hepp has been warning, may well not scale. I honestly do not know what we can do about that. Some citation formats use "In:" to indicate the part/whole. Could we use something like "inPeriodical" or "inPublication"? (the latter would include book chapters in books). (And probably a reverse relation, since @rev isn't liked by > everyone; and since in some cases the workflow does go from container to > contained.) > I think there has been some push-back about having those kinds of reverse relations in schema. However, Dan's proposal does have both "directions", I believe. Can we do without them for a first step proposal? Do we have examples that can help us make this clear? > (The articles here, having paginations, are intrinsically parts of > something paged – otherwise the pagination property wouldn't be very > useful (just numberOfPages would do).) Yes, although there are other things that can be "paged," like book chapters, and like the comic book stories, which is why I thought it would be good to have pagination a kind of "free floater" in Intangible so it could be used wherever needed. > > By the way: it seems that the headlines in the wiki page are a bit off. > The section under "Intangible" really should be for Article, right? And > the "Thing > CreativeWork > Article" section seems to specify the > addition of the Periodical class. Mmmm. The Intangible section really is a suggestion for Intangible. What makes it odd is that what I specified are three properties but no class. Perhaps they would fit somewhere subbed to "StructuredValue"? I admit I couldn't really decide what to do with them, but I wanted them outside of periodical/article because they could be needed elsewhere. "Paging" as the class, perhaps? Paging (class) pagination startPage endPage As for "Thing > CreativeWork > Article" -- I worded that badly. It needs to say that Article needs to ALSO be sub to Periodical (as well as to CreativeWork). So we should have: Thing > CreativeWork > Article Thing > CreativeWork > Periodical Thing > CreativeWork > Periodical > Article If this makes sense, I'll fix the wording. If not, then we need to fix the proposal. It may be that the third item above is sufficient, but with schema I find it hard to grasp what the "sub-" relationships actually do since the end result is a flat vocabulary. I dislike deep nesting, which may be what is motivating me in this regard. Again, whatever works, I don't feel strongly either way. kc > > Cheers, > Niklas > > > > On Mon, Dec 9, 2013 at 12:18 AM, Young,Jeff (OR) <jyoung@oclc.org > <mailto:jyoung@oclc.org>> wrote: > > The world is full of whole/part relationships. With this approach, > won't Schema.org be overwhelmed by custom partOfFoo properties where > the range Foo classname is encoded in the property name? > > Jeff > > Sent from my iPad > > > On Dec 8, 2013, at 6:13 PM, "Karen Coyle" <kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> wrote: > > > > Thanks, Niklas - > > > > So you are suggesting that we need partOfPeriodical to make this > work smoothly? And that would be a new property in Article? If I > understand that correctly, we would then have: > > > > Article > > > > adds: > > * partOfPeriodical > > - type: Periodical > > > > kc > > > >> On 12/8/13, 1:42 PM, Niklas Lindström wrote: > >> Hi Karen, > >> > >> Great! I did two variants of the article example, inlined below. In > >> these, the items are linked (using our suggested > partOfPeriodical). They > >> also overcome a problem with the current version in the wiki, which > >> describes four separate items (two articles and two periodicals). > >> > >> The first is in RDFa, and uses @resource to identify the article and > >> periodical: > >> > >> - - - 8< - - - > >> > >> <div vocab="http://schema.org/" typeof="Article"> > >> <strong>Title:</strong><span property="name"> Be Careful > What You > >> Wish For: FRBR, Some Lacunae, A Review</span><br /> > >> <strong>Author:</strong> <span property="author">Smiraglia, > >> Richardp.</span><br /> > >> <strong>Subjects:</strong> <span > property="subject">Catalog</span> > >> ; <span property="subject">Works</span> <br /> > >> <strong>Is Part Of:</strong> > >> <div property="partOfPeriodical" typeof="Periodical" > resource="#pdl"> > >> <span property="name">Cataloging & Classification > >> Quarterly</span>, > >> <span property="datePublished">2012</span>, > >> Vol.<span property="volumeNumber">50</span>(<span > >> property="issueNumber">5</span>),</div><div> > >> p.<span property="pagination">360-368</span> [Peer Reviewed > >> Journal]<br /> > >> <strong>Description:</strong> <span property="description">The > >> library catalog as a catalog of works was an infectious idea, which > >> together with research led to reconceptualization in the form of the > >> FRBR conceptual model. Two categories of lacunae emerge—the > expression > >> entity, and gaps in the model such as aggregates and dynamic > documents. > >> Evidence needed to extend the FRBR model is available in > contemporary > >> research on instantiation. The challenge for the bibliographic > community > >> is to begin to think of FRBR as a form of knowledge organization > system, > >> adding a final dimension to classification. The articles in the > present > >> special issue offer a compendium of the promise of the FRBR > >> model.</span></div><br /> > >> <div resource="#pdl"><strong>Publisher:</strong> > >> <span property="publisher">Taylor & Francis > Group</span><br /> > >> <strong>Source:</strong> Routledge, Taylor & Francis > Group<br /> > >> <strong>ISSN:</strong> <span > property="issn">0163-9374</span> ; > >> <strong>E-ISSN:</strong> <span > property="issn">1544-4554</span> > >> ;</div> > >> <strong>DOI:</strong> <a > >> href="http://dx.doi.org/10.1080/01639374.2012.682254" > >> property="url">10.1080/01639374.2012.682254</a> > >> </div> > >> > >> - - - >8 - - - > >> > >> Check this out in <http://rdfa.info/play/> to see the data in > action. > >> > >> The other is an attempt to use @itemref in microdata to do the > same thing: > >> > >> - - - 8< - - - > >> > >> <div> > >> <span itemscope itemtype="http://schema.org/Article" > >> itemref="partof details"> > >> <strong>Title:</strong><span itemprop="name"> Be Careful > What You > >> Wish For: FRBR, Some Lacunae, A Review</span><br /> > >> <strong>Author:</strong> <span itemprop="author">Smiraglia, > >> Richardp.</span><br /> > >> <strong>Subjects:</strong> <span > >> itemprop="subject">Catalog</span> ; <span > >> itemprop="subject">Works</span> <br /> > >> <strong>Is Part Of:</strong> > >> </span> > >> <div id="partof" itemprop="partOfPeriodical" itemscope > >> itemtype="http://schema.org/Periodical" itemref="publ"> > >> <span itemprop="name">Cataloging & Classification > >> Quarterly</span>, > >> <span itemprop="datePublished">2012</span>, > >> Vol.<span itemprop="volumeNumber">50</span>(<span > >> itemprop="issueNumber">5</span>),</div><div id="details"> > >> p.<span itemprop="pagination">360-368</span> [Peer Reviewed > >> Journal]<br /> > >> <strong>Description:</strong> <span itemprop="description">The > >> library catalog as a catalog of works was an infectious idea, which > >> together with research led to reconceptualization in the form of the > >> FRBR conceptual model. Two categories of lacunae emerge—the > expression > >> entity, and gaps in the model such as aggregates and dynamic > documents. > >> Evidence needed to extend the FRBR model is available in > contemporary > >> research on instantiation. The challenge for the bibliographic > community > >> is to begin to think of FRBR as a form of knowledge organization > system, > >> adding a final dimension to classification. The articles in the > present > >> special issue offer a compendium of the promise of the FRBR > >> model.</span></div><br /> > >> <div id="publ"><strong>Publisher:</strong> > >> <span itemprop="publisher">Taylor & Francis > Group</span><br /> > >> <strong>Source:</strong> Routledge, Taylor & Francis > Group<br /> > >> <strong>ISSN:</strong> <span > itemprop="issn">0163-9374</span> ; > >> <strong>E-ISSN:</strong> <span > itemprop="issn">1544-4554</span> > >> ;</div> > >> <strong>DOI:</strong> <a > >> href="http://dx.doi.org/10.1080/01639374.2012.682254" > >> itemprop="url">10.1080/01639374.2012.682254</a> > >> </div> > >> > >> - - - >8 - - - > >> > >> This one became a bit more cumbersome, since @itemref is more > tricky to > >> use when markup is interweaved like this. > >> > >> (Granted, I am more acquainted with RDFa (unsurprisingly, being > a member > >> of the RDFa 1.1 WG). And I readily admit to favor the @resource > >> mechanism in RDFa over @itemref in microdata. So I may have > overlooked > >> some trick to make it work better. There is also @itemid, which in > >> theory is analogous to @resource. But I'm not sure whether it is > good > >> practice, or even valid, to use it repeatedly in the same manner.) > >> > >> Cheers, > >> Niklas > >> > >> > >> > >> On Sun, Dec 8, 2013 at 10:09 PM, Karen Coyle <kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net> > >> <mailto:kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net>>> wrote: > >> > >> All, > >> > >> Since there was interest I went ahead and did a first draft of a > >> minimalist proposal. I believe I have designed it such that, > given > >> the flat nature of schema.org <http://schema.org> > <http://schema.org>, it does not > >> preclude the more complete proposal offered by Dan. > >> > >> > http://www.w3.org/community/__schemabibex/wiki/Periodical___Article_minimal > >> > <http://www.w3.org/community/schemabibex/wiki/Periodical_Article_minimal> > >> > >> I did the examples there, and what with my limited coding skills, > >> you should expect to find (and feel free to fix) errors. > Hopefully > >> the examples actually exemplify the proposal. At least, that > was my > >> intention. I'll do more validation and testing of them if I > find time. > >> > >> All suggestions, comments, corrections welcome. > >> > >> kc > >> -- > >> 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 Monday, 9 December 2013 04:07:40 UTC