Re: schema.org property proposal: workPerformed

On Tue, Apr 08, 2014 at 08:22:59AM +0200, Karen Coyle wrote:
>
>
>On 4/7/14, 2:25 PM, Niklas Lindström wrote:
>>
>>
>>
>>    I've made a test build using the new codebase that has the Periodicals
>>    etc proposal plus this workPerformed proposal plus VisualArtwork,
>>    available as
>>
>>    http://sdo-culture-bundle.appspot.com/PublicationVolume
>>    http://sdo-culture-bundle.appspot.com/Periodical
>>
>>
>>Like others said in another thread (and as can be expected, being a part
>>of the SchemaBibEx group), I'm glad to see this proposal moving forward.
>>
>>(It would be nice to see the BIBO mappings from the proposal as well,
>>both in prose and in RDFS if possible.)
>
>I would be very interested to get feedback on this proposal from 
>someone who is using BIBO or SPAR [1] primarily for academic 
>citations. There is a long-standing bifurcation between the library 
>community and its cataloging, and the academic/researcher community, 
>which has different bibliographic goals. Presuming that this proposal 
>should be usable by both, perhaps a proof of concept is needed. Would 
>it be appropriate to solicit comments from the developers or users of 
>these standards?

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

... and so instead of restricting things to a flat Periodical <->
Article relationship with key-value properties, we used a more
relational Periodical <-> Publication(Issue|Volume) <-> Article
relationship that allowed for much richer modelling (and of course one
can leave the Publication(Issue|Volume) intermediate entities out
entirely for periodicals such as Arxiv that have no use for such
concepts).

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.

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!

And continuing to quote from that section:
""
In all, BIBO contains 69 classes, 52 object properties, 54 data
properties and 14 individuals, while FaBiO contains 239 classes, 69
object properties, 63 data properties and 15 individuals.
"""

schema.org probably falls into the middle of this measuring contest when
it comes to bibliographic classes & properties, but we're not trying to
model full-on FRBR the way SPAR is. And that (in my opinion) is a good
thing.

Also, the same post under "Are the SPAR Ontologies too complex?" says:
"""
These last three RDF examples, for PRO, PSO and PWO, show the richness
of detail that can be expressed using the SPAR Ontologies. Clearly these
RDF examples would be tedious to write manually. The creation of such
complex metadata for large document collections should be undertaken by
‘smart’ applications with user-friendly interfaces that hide the
complexity of the formalism/vocabularies used.

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.

Received on Tuesday, 8 April 2014 07:29:46 UTC