W3C home > Mailing lists > Public > public-vocabs@w3.org > April 2014

Re: Citation markup with Periodical proposal

From: Dan Scott <dan@coffeecode.net>
Date: Wed, 9 Apr 2014 13:49:22 -0400
To: Niklas Lindström <lindstream@gmail.com>
Cc: Karen Coyle <kcoyle@kcoyle.net>, Gregg Kellogg <gregg@greggkellogg.net>, "public-vocabs@w3.org" <public-vocabs@w3.org>
Message-ID: <20140409174921.GA321@denials>
On Wed, Apr 09, 2014 at 07:02:23PM +0200, Niklas Lindström wrote:
>Hi Dan,
>On Wed, Apr 9, 2014 at 6:19 PM, Dan Scott <dan@coffeecode.net> wrote:
>> On Wed, Apr 9, 2014 at 12:13 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>> >
>> >
>> > On 4/9/14, 5:04 PM, Gregg Kellogg wrote:
>> >
>> >> Hi Karen, I get the following Turtle for your example:
>> >>
>> >
>> > Thanks, Gregg. And special thanks for using turtle, which I find easier
>> to
>> > read than JSON (much less JSON-LD).:-)
>> >
>> >
>> >>
>> >> Note that the article and the periodical are not related to each
>> >> other. You're probably missing an @itemprop on the div introducing
>> >> the new @itemtype. Perhaps schema:publisher?
>> >
>> >
>> > This is the nut of the problem. The journal unfortunately isn't the
>> > publisher -- that would be easier than the reality. The publisher is
>> > something like "Elsevier", the journal is a publication, the article is
>> *in*
>> > the journal. In a citation, it is left to a human brain to make the
>> > connection. In the examples [1] the connection is article (incl.
>> pagination)
>> > -> issue  -> volume -> journal. However, note that this is not the order
>> > that is used in MLA citations, which go: article -> journal -> volume ->
>> > issue -> date -> pagination.
>> >
>> > [slightly abbreviated from actual example]
>> >
>> > @prefix : <http://schema.org/> .
>> >
>> > [] a :ScholarlyArticle ;
>> >     :author "Smiraglia, Richard P." ;
>> >     :isPartOf <#issue> ;
>> >     :name "Be Careful What You Wish For: FRBR, Some Lacunae, A Review" ;
>> >     :pageEnd "368" ;
>> >     :pageStart "360" ;
>> >
>> > <#issue> a :PublicationIssue ;
>> >     :datePublished "2012" ;
>> >     :isPartOf [ a :PublicationVolume ;
>> >             :isPartOf <#periodical> ;
>> >             :volumeNumber "50" ] ;
>> >     :issueNumber "5" .
>> >
>> > <#periodical> a :Periodical ;
>> >     :name "Cataloging & Classification Quarterly" .
>> >
>> > ************
>> >
>> > Could someone who is better than I am at coding try marking up the MLA in
>> > html example that I gave using this vocabulary? I've tried, but I can't
>> > figure out an elegant way to create this structure with the items in this
>> > order:
>> >
>> > article
>> >         author
>> >         title
>> > periodical
>> >         title
>> >         volume#
>> > issue
>> >         issue#
>> >         issue date
>> > article
>> >         pages
>> >
>> > Thank you!
>> So if you want a flat / simplistic structure that does not surface any
>> structure in the relationship between the Periodical,
>> PublicationVolume, and PublicationIssue, the proposal as it stands
>> would use "isPartOf" to relate the Periodical, PublicationVolume, and
>> PublicationIssue to the Article, like the following:
>> <p>
>> <div itemscope itemtype="http://schema.org/ScholarlyArticle">
>> <span itemprop="author">Carlyle, Allyson.</span>&quot:
>> <span itemprop="name">Understanding FRBR as a Conceptual Model: FRBR
>> and the Bibliographic Universe</span>&quot;
>> <div itemprop="isPartOf" itemscope itemtype="http://schema.org/Periodical
>> ">
>> <em><span itemprop="name">Library Resources and Technical
>> Services</span></em></div>v.
>> <span itemprop="isPartOf" itemscope itemtype="PublicationVolume"><span
>> itemprop="volumeNumber">50</span></span>, no.
>> <span itemprop="isPartOf" itemscope itemtype="PublicationIssue"><span
>> itemprop="issueNumber">4</span>(<span itemprop="datePublished">October
>> 2006</span></span>):
>> <span property="pageStart">264</span>-<span
>> property="pageEnd">273</span></div> Print.</p>
>> issueNumber and volumeNumber have rangeIncludes directives that limit
>> them to PublicationIssue and PublicationVolume respectively, so
>> "sufficiently distinctive" doesn't really matter; using those
>> properties directly on Article would simply be an error.
>> Does that work for you?
>My email client didn't properly update in time, so I missed your take.
>Which provides an interesting contrast regarding nesting isPartOf (which,
>being conceptually transitive, makes your example logical, albeit as you
>say, lacking some connections). You also touch on the domain of issueNumber
>and volumeNumber (I take it you meant domainIncludes?), where as you might

domainIncludes, yes, good catch! /me points at a lack of sleep...

>remember I wasn't opposed to more gritty and conflational approaches (not
>necessarily *for* that, but I can tolerate it when precision gets in the
>way of something useful). :)

I do recall that, yes. A lot of this conversation is very familiar!
For the benefit of those who are not SchemaBibEx members, that's because
after making a fair bit of progress on an inital Periodical / Issue /
Volume proposal, SchemaBibEx walked through a similar minimalist
approach Karen proposed back in December, iterated towards the proposal
as it currently stands through January, and in good faith agreed to
bring that proposal forward to WebSchemas for adoption.

Some of the rationale for the proposal we have brought forward is that
it offers a balance of both deeply structured and "flat" approaches (via
the important addition of the "isPartOf" and "hasPart" properties to
CreativeWork) without requiring the pollution and confusion of adding
many more properties directly to CreativeWork, and without requiring the
proliferation of "partOfPublicationVolume / partOfPublicationIssue /
partOfPeriodical" properties that we see with the similar Series /
Season / Episode structure.

Why would those properties have to be domainIncluded to CreativeWork,
and not just to Article? Because of course there are many classes other
than Article and its children that can be part of a volume or issue:
Code, Diet, Map, Painting, Photograph, and very likely others.

And we've seen very recently that more precise markup is gaining
traction: https://support.google.com/webmasters/answer/4620709?hl=en for
example requires the use of the contactPoint property on Organization to
specify a specific ContactPoint, rather than just making use of the
direct email / telephone properties that live directly on Organization.

For what it's worth, the FaBiO example that Karen posted earlier also
actually uses a hierarchical "partOf" set of relationships:
"fabio:ResearchPaper frbr:partOf [ a fabio:JournalIssue frbr:partOf [ a
fabio:JournalVolume frbr:partOf [ a fabio:Journal ] ] ]" and the
OWL/RDFS in the FaBiO ontology bears out those restrictions for those
classes. And we've already seen that BIBO uses a hierarchical
relationship (with the acknowledged difference being that they have
volume as a property on issue; a difference, again, that we discussed
deeply back in December / January).

So given that the schema.org proposal slants toward hierarchical markup,
I think we're in quite good company. At the same time, we can also
support quite flat markup - the cost is just one additional intermediary
type - and the proposal fills a significant gap in the schema.org
vocabulary.  If the WebSchemas community feels a need for more examples,
those are easily added (in fact, at the last SchemaBibEx call we agreed
to shift into "documenting best practices and supporting the user
community" mode for precisely that reason).

Finally, I would expect most citations expressed in schema.org would be
generated by a tool, just as most COinS markup is generated by tools
such as [1] today. For those who are hand-coding their sites, one obvious
approach would be to create a web UI into which you paste your citation,
highlight a piece of the citation, and tell the tool what the
highlighted piece is; and HTML that encodes the citation with RDFa or
JSON-LD or microdata would get spit out the other side.

1. For example
- sadly the actual site is currently offline
Received on Wednesday, 9 April 2014 17:49:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:39 UTC