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

Re: schema.org property proposal: workPerformed

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Tue, 08 Apr 2014 16:53:48 +0200
Message-ID: <53440D7C.1070901@kcoyle.net>
To: Dan Scott <dan@coffeecode.net>
CC: public-vocabs@w3.org

On 4/8/14, 9:29 AM, Dan Scott wrote:
> On the BIBO front, at least, schemabibex did our homework before
> bringing the Periodical proposal to public-vocabs. See this thread
> involving Bruce D'Arcus from December 2013, where he cautioned against
> adopting too flat of a design and recommended a more relational
> approach:
> https://groups.google.com/d/msg/bibliographic-ontology-specification-group/03v0_4JHgR0/yvmmMr9dB8UJ

Dan, actually, the recommendation on the relational approach was from 
you in that email:

"At this point, I'm in favour of the more relational approach 
(confession: I wrote most of it), but now that I've seen what Bibo has 
done (thanks to Ross Singer for the nudge) with the Periodical -> Issue 
-> Article, I'm willing to cut out PeriodicalVolume so that our 
ontologies can more or less line up." (Dan)

Bruce D'Arcus (of BIBO) said:

"A volume is a level of abstraction that I would say is largely
meaningless for purposes of citations. So I don't think it's worth the
extra modeling complexity, and so we capture what we need with a
simple data property (text string). "


"I will say, based on that, that the key design question is whether you 
go flat key-value (which is often the initial impulse), or whether you
have some level of relational design. BIBO tries to hit a sweet-spot
that works for the vast majority of citation-oriented use cases (many
of which the flat approaches, that start with bibtex, ignore). "

I think that it may be useful to hear if BIBO and other 
citation-oriented use cases consider the schema.org proposal "sweet enough."

> For a period of time we had been working towards aligning the Periodical
> proposal as closely as possible with BIBO, a key difference is that we
> ultimately chose to add PublicationVolume as a separate class, whereas
> BIBO chose to simply add "volume" as a textual property to their
> Document class (roughly equivalent to our CreativeWork). A rehash of the
> schemabibex discussion about aligning with BIBO is at
> http://lists.w3.org/Archives/Public/public-schemabibex/2013Dec/0076.html
> for those interested in the gory details.

That's really only part of the discussion. Since the email you quote is 
one sent by you, I'll now quote from that I contributed:


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


I do think that we have a general difference of opinion, which to me 
translates to different use cases. I see one use case as the citation, e.g.

"Carlyle, Allyson. Understanding FRBR as a Conceptual Model: FRBR and 
the Bibliographic Universe. Library Resources and Technical Services, v. 
50, no. 4 (October 2006): 264-273."

This is essentially an identifier for the article, and the remainder of 
the volume, or other volumes of the same periodical, are not of interest.

The other use case has to do with bibliographic control of periodical 
publications, such as:

     Issue (number and date)
       Article or section

These two cases have a lot of data elements in common, but, as D'Arcus 
says, in the citation use case the volume is abstract, and the structure 
of the journal publication pattern is of secondary interest. Citations 
are generally flat metadata. So we mustn't conclude that the similarity 
of data elements = the same use case.

The question we need to put to the group here is: can we find that sweet 
spot between these two cases? My concern is that a standard that 
attempts to re-create the complex structure of periodical publication 
may be detrimental to the acceptance for those whose needs are fulfilled 
with a simpler, flat structure.

> On the SPAR front, as an ontology published in 2013 it seems a bit
> unlikely that we'll find many objective adopters at this point, but the
> developers' own comments at
> http://semanticpublishing.wordpress.com/2013/03/01/lld5-using-spar-ontologies/
> under "Comparison of FaBiO with BIBO" has some interesting comments
> around BIBO:
> """
> For example, BIBO lacks the concept of “Volume” as a distinct class (the
> equivalent of fabio:JournalVolume), among other bibliographic classes
> that have a hierarchical partitive relationship to one another (i.e.
> Article > Issue > Volume > Journal, as used in the first FaBiO RDF
> example above.
> """
> Hey, looks like we nailed that concern with our addition of
> PublicationVolume!

I'm not at all sure that FaBiO periodicalVolume  [1] (or journalvolume) 
is equivalent to what is being proposed for schema.org. In my reading, 
the bibliographic descriptive elements of FaBiO are quite flat, so 
although there is a data element for periodical volume, there is no 
defined structure between it and the periodical issue. There aren't many 
examples (another good reason to contact the interested parties) but 
here is one:

:intertextual-semantics a fabio:ResearchPaper
; dcterms:creator :marcoux , :rizkallah
; frbr:realization :version-of-record .
:version-of-record a fabio:JournalArticle
; dcterms:title “Intertextual semantics: A
semantics for information design”
; fabio:hasPublicationYear “2009”^^xsd:gYear
; prism:doi “10.1002/asi.21134”
; frbr:embodiment :printed , :html ,:pdf
; frbr:partOf [ a fabio:JournalIssue
; prism:issueIdentifier “9”
; frbr:embodiment :printed-issue
; frbr:partOf [ a fabio:JournalVolume
; prism:volume “60”
frbr:partOf [ a fabio:Journal
; dcterms:title “Journal of the
American Society for Information Science and
Technology” ] ] ] .


I may be reading this wrong, but it looks to me like issue and volume 
are non-dependent elements in FaBiO (as they are in BIBO). This makes 
the citation essentially flat, since at no point does the structure here 
state that issue 9 is part of volume 60.

My reason for preferring a flat solution is that the pattern of journal 
title -> volume -> issue may be typical but is violated in numerous 
cases. There are part - > volume -> issue, there are double issues, 
there are separate indexes that may cover more than one volume, there 
can be issues without volumes, and surely someone has done issues with 
subordinate volues (anything is possible) -- it's a huge mess, so my 
vote is to leave the complex structure to systems that specialize in 
periodical control, but to provide a fairly open view for general use in 



> Clearly, if one wishes to publish just a few simple metadata statements
> about a document, there are simpler vocabularies such as Dublin Core and
> BIBO that one could use as alternatives to the SPAR ontologies. But none
> of these are as expressive, as explained in [1]. For example, none
> permits designation of author or editor roles in the context of specific
> documents, organizations and time spans, as exemplified above. So, if
> one needs to publish as linked data a mass of bibliographic data with
> different kinds of complex relations among them, SPAR can be a good
> choice.
> """
> Reading that, SPAR is clearly aiming at a different audience than
> schema.org. On the other hand, I think some of the recent discussions
> around hasRole in schema.org are going to let us reach much of the same
> richness of expression that SPAR is targeting, while continuing to offer
> the ease of use to which schema.org aspires, along with a reasonable set
> of mappings to BIBO.

Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet
Received on Tuesday, 8 April 2014 14:54:24 UTC

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