- From: Young,Jeff (OR) <jyoung@oclc.org>
- Date: Fri, 28 Jun 2013 16:08:27 +0000
- To: Dan Scott <denials@gmail.com>
- CC: Ed Summers <ehs@pobox.com>, Shlomo Sanders <Shlomo.Sanders@exlibrisgroup.com>, "public-schemabibex@w3.org" <public-schemabibex@w3.org>
Dan, > > It's pointless to add FRBR/Holdings to Schema.org because they > already have the critical components built-in to their > schema:Product/schema:Offer branch. It's presumably fair to say that > most SchemaBibEx members don’t want to look at it that way, but there > it is. > > Jeff: > > At this point, I would avoid saying anything about what most > SchemaBibEx members want or don't want! Touchy subject area :) I noticed that. :-) > I volunteered to experiment with modelling library holdings because I'm > interested in improving Evergreen's schema.org integration - and your > suggestion of using Product/Offer seems workable, so I'm going to give > that a shot. > > Some of my (still half-formed) thoughts on FRBR in schema.org: > > During the last call, I proposed (via chat) that Freebase's adaptedWork > / adaptedFrom properties might make more sense than the proposed > hasInstance / isInstanceOf for expressing relationships between > CreativeWorks. I like adaptedFrom and it would work as an alternative for some of the "hasInstance/isInstanceOf" cases. (I don't like the hasInstance/isInstanceOf proposal, so I'm currently using skos:broader/narrower for this purpose instead.) I would argue against proposing inverse properties since Schema.org doesn't currently handle them very well. > I'm not sure we really need a Platonic ideal / FRBR Work > in schema.org; it seems to be a potential rat hole that would be better > avoided, as the abstract "Work" is subject to revisionism and > argumentation for little benefit to the linked data effort. I agree. Jeff > For example: would the abstract CreativeWork for "The Little Mermaid" > be the Disney creation? Surely not; it would be the Hans Christian > Andersen work on which the Disney story was based, but it would not be > the English translation; it would be "Den lille havfrue" - but wait, > Andersen's work doesn't even include "Ariel" as a character's name, and > surely the vast majority of people looking for "The Little Mermaid" > actually want the Disney films / books / tv series / video games / > figurines / stickers / whatever... and perhaps at some point in the > future we will discover that Andersen's work was based on a previously > existing oral tale. Do we even want to try to have to express that, and > maintain that, when it seems much better suited to the realm of > historical literature academics & their research papers & books & > conference proceedings? > > In short, I don't think an abstract CreativeWork and all of the FRBR > Work baggage that would carry offers significant benefits to our > efforts. I, for one, would be happy to link off to, say, the wikipedia > page on "The Little Mermaid" (either > http://en.wikipedia.org/wiki/The_Little_Mermaid or > http://en.wikipedia.org/wiki/The_Little_Mermaid_(1989_film) or > http://en.wikipedia.org/wiki/The_Little_Mermaid_(franchise) or > http://en.wikipedia.org/wiki/The_Little_Mermaid_(disambiguation)) or > their Freebase equivalents, and let the linked data lead interested > parties to explore the connections and arguments further. > > Dan > > P.S. I apologize for the half-formedness of these thoughts; I'm > starting a sabbatical next week, and rather amusingly back in August > 2012 part of my sabbatical proposal was to work on expressing library > system metadata in schema.org and structured data vocabularies in > general... so the timing of this group forming was in some ways > horrible (as I have been unable to commit the time that it deserved), > but now I can start to put my back into it in a serious way and hope to > be able to contribute both more concretely (by way of continuing > implementations of the group's proposals in Evergreen with real library > data) as well as more deeply (by being able to focus on the subject > matter at more length).
Received on Friday, 28 June 2013 16:08:57 UTC