Re: CreativeWork relationships

All four of these properties seem like good additions. Some care will need
to go into the descriptions so it is clear that my paperback *Moby Dick* is
an example of *Moby Dick* while the *Moby Dick: The Graphic Novel* is based
on the original.

This may be too far afield, but has there been any thought to a '*
refersToWork**' *to capture the relationship between commentaries and
criticisms to the original work. A commentary on *Othello* is not an
example of *Othello* or based on *Othello*, but it would be nice to note
that relationship.


Vicki Tardif Holland | Ontologist |

On Fri, Sep 20, 2013 at 7:52 AM, Wallis,Richard <>wrote:

>  Triggered by some of the discussion around the recent Audiobook proposal<> I
> posted on behalf of the SchemaBibEx Group(snippet below),  I think we need
> to address the issue of adding some properties to CreativeWork allowing the
> description of relationships between CreativeWorks, as a more general
> issue.
>  In the Audiobook discussion '*isBasedOn*' has been suggested to
> reference the original literary work.
>  Within the SchemaBibEx group we have been discussing the relationship
> between Works (in the FRBR<> sense
> of Work) and examples of that [conceptual] work.  As Karen points out there
> is some work on Work (from Freebase, Open Library, LibraryThing, WorldCat,
> etc.) in this area which could benefit from being able to describe
> relationships they are defining.  As she also points out, apart from these
> organisations, there is little metadata available yet so we may be in a
> chicken or egg situation as to adoption.
> Draft proposals for this being:
>    - '*workExample*' - Example/instance/realization/derivation of the
>    concept of this creative work.  e.g..  The paperback edition
>    - '*exampleOfWork'* - The creative work that this work is an
>    example/instance of.
>  Karen also suggests a "same work" relationship where you could for
> instance relate the paperback to the hardback - how about '*sameWorkAs*'?
>  I would support the adoption of all four of these.
>  Adopting something like FRBR would be too complex for a a general
> vocabulary like - we should be looking for a [smallish] number
> that will be useful in relating works of many types together.
>  A KISS approach is desirable, however addressing it piecemeal around
> individual proposals may not be the simplest way when the core CreativeWork
> type is probably the best place to add these properties. As they are just
> as applicable to sculptures and paintings as books movies and audiobooks or
> even webpages.
>  I suspect we are looking at a few, more focused, sub-properties of a
> generic workRelationship property (domain and range of CreativeWork).
>  Coming to my point in this rambling email.  Can we get a consensus on
>  a) there being a need to describe relationships between CreativeWorks in
> this way, and  b) a smallish set would do the job, at least for now.
>  If we can, could we then run a suggestion and agree/disagree process to
> try to define that shortish list of candidates.
> ~Richard
>  [From Proposal: Audiobook]
> That said, we (schema BibEx) are contemplating links between CreativeWorks
> for those instances where there are identifiers that can be used for that
> purpose. I think it would be preferable that such linking properties be as
> general as possible, and one possibility is to allow any number of
> CreativeWorks to state a "same Work" relationship between them. So all of
> those editions of Moby Dick can state that they represent the same work
> (with links between them) or they can all state that they represent the
> same work described in If there is a
> "Work" record (approximating the FRBR sense of Work) then you can declare
> any edition to the be same work as that record's URL. (Freebase, Open
> Library, LibraryThing, and apparently soon WorldCat, have identifiers for
> Work, although their definitions of Work vary among them.) The variety of
> possible relationships is enormous, and so I think that beginning with a
> KISS approach while we see how this pans out would be wisest.

Received on Friday, 20 September 2013 13:48:48 UTC