- From: Dan Scott <dan@coffeecode.net>
- Date: Tue, 8 Apr 2014 03:29:15 -0400
- To: Karen Coyle <kcoyle@kcoyle.net>
- Cc: public-vocabs@w3.org
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