Re: First draft minimalist periodical/article proposal

On Sun, Dec 8, 2013 at 11:07 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:
> 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.

Well, we could ditch the "partOfXYZ" properties and rely on the
generic "partOf" property (which also requires the Collection proposal
to be adopted)... but that only works well for relationships that
point to strong, fleshed-out types. If you use a "partOf" generic
property and intend to point to a Periodical type, then you either
have to flesh it out inline or point to a URL for the processor to be
able to do something useful with that information. If you have
properties with a narrower range, however, like "partOfPeriodical" and
"partOfPeriodicalIssue" properties, then you _could_ get away with
supplying just the text string for the title of the Periodical and the
PeriodicalIssue number and a processor will have a much better basis
for figuring out the right bits.

This is, by the way, the simplified markup approach that is available
with the Periodical/PeriodicalVolume/PeriodicalIssue/Article
hierarchy; while you always hope that people will follow the richer
path of actually fleshing out the types, one _could_ just supply text
strings for partOfPeriodical, partOfPeriodicalVolume, and
partOfPeriodicalIssue when describing an Article, and a processor
would still be able to do pretty useful things with it.

To take Nicklas's excellent RDFa example and make it work in this
not-recommended-but-still-likely-to-happen-in-some-cases-text-instead-of-types
way just requires sliding the </div> tag up and changing the names of
the two properties:

  <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 &amp; Classification Quarterly</span>,
      <span property="datePublished">2012</span>,</div>
      Vol.<span property="partOfPeriodicalVolume">50</span>(<span
property="partOfPeriodicalIssue">5</span>),<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 &amp; Francis Group</span><br />
      <strong>Source:</strong> Routledge, Taylor &amp; 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>

> 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?

FWIW, I followed the Series/Season/Episode convention in including the
bidirectional properties. The "hasXYZ" naming convention is well
established in that hierarchy, and the "partOfXYZ" that I moved to in
my proposal reflects Dan Brickley's response to Karen where he
mentioned the possibility of changing naming conventions for
properties and Types that currently differ only by case. As a
reminder, what Dan said was "The schema.org team haven't yet decided
on what to do, but a possibility is to introduce new hasXyz property
names, and mark the original form as deprecated in favour of the
has-based version." -
http://lists.w3.org/Archives/Public/public-vocabs/2013Dec/0037.html.

>> (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.

>From what I can tell reading the RDF Schema in
http://schema.org/docs/schema_org_rdfa.html, I don't think schema.org
properties really need a home. I think you can just add a
"domainIncludes" assertion for a given property to add it to that
type, if it belongs there.

>> 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.

Yes, the third line follows the convention of the docs at
http://schema.org and should be all you need. For example,
http://schema.org/NewsArticle is a subclass of "Thing > CreativeWork >
Article" and is expressed as "Thing > CreativeWork > Article >
NewsArticle" .

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

On the topic of Series, the reason I didn't make Periodical a subclass
of Series was because it carried an awful lot of media-specific
baggage with it, and as the only two properties of interest were
endDate and startDate, I thought it was simpler to just subclass
directly from CreativeWork and extend the domain of those properties
accordingly. (An alternative was to shift the media-specific
properties into a MediaSeries subclass that TVSeries and RadioSeries
could pull from, and then that would enable Periodical to be a
subclass of Series... but for just two properties, that seemed to be
an awful lot of work for very little gain).

Received on Monday, 9 December 2013 05:29:57 UTC