Re: CreativeWork relationships

Hi Phil,

On Fri, Sep 20, 2013 at 4:28 PM, Phil Barker <phil.barker@hw.ac.uk> wrote:

>
> Hello. There is already an isBasedOnUrl property of creative works. It
> came in to schema from the LRMI work and is used to point to "a resource
> that was used in the creation of this resource". The use case in that
> context was indicating the sort of derivation/modification of a creative
> work (in the copyright sense of the words) that is allowed by Creative
> Commons licences without the "No Derivatives" clause.
>
> The suggestions below look sound. My one concern is that there might be a
> collision between it and isBasedOnUrl. I assume that the isBasedOn property
> will indicate a relationship between CreativeWorks(*), so there is scope
> for confusion between the URL provided for isBasedOnUrl and a URL provided
> for the Url property of the CreativeWork at the end of an isBasedOn
> property (I hope that is easier to understand than to state in words).
> Would the proposed isBasedOn relationship be entirely distinct from the
> relationship indicated by isBasedOnUrl, would it be a sub/superset? Most
> importantly how is any distinction explained?
>

Well, 'isBasedOnUrl' has a textual value as range – the URL itself. You
might use it as an indirect reference to a thing which has this value for
its 'url' property (although this isn't really defined). The URL, when used
as an *identifier*, then names some article whose subject matter is the
thing, somehow (possibly using 'about'). Thus, the value could be "
http://en.wikipedia.org/wiki/The_Lord_of_the_Rings", with the *intent* of
referencing that *work* – not the wikipedia article about it. That pattern
may be fine for near-matches using URLs as foreign keys, but it isn't
enough for the use cases here intended. (Which are just like most other
usages of schema.org – e.g. relating Persons to Things, Products with
Offers, and so on).

So by having a range of 'URL', 'isBasedOnUrl' excludes direct references.
It cannot be used following Linked Data practises of identifying things
with URLs, neither can it be used to link unnamed entities directly
described (i.e. following the general logical foundation of the resource
description framework – or the tree-based informal microdata variant). Thus
it cannot as it stands link a CreativeWork to another.

An option would of course be to just extend the range of 'isBasedOnUrl',
but the name of that would then be rather odd. Schema.org does mainly use a
pattern of direct relations between things, using "natural" names for the
properties. (You may use URLs as identifiers for those things, and/or link
unnamed things described in the same page.)

That's why I recommended to define 'isBasedOn' (as a companion to
'isBasedOnUrl' if you will), with both a domain and range of CreativeWork.

Semantically, I suppose their relation is something like (pardon my OWL):

    :isBasedOnUrl owl:propertyChainAxiom (:isBasedOn :url) .

Cheers,
Niklas



>
> Phil
>
>
>
> *i.e. I don't suppose we are going into possibilities of
> http://en.wikipedia.org/wiki/Macbeth_(character) isBasedOn
> http://en.wikipedia.org/wiki/Macbeth_of_Scotland
>
>
> On 20/09/2013 12:52, Wallis,Richard wrote:
>
> Triggered by some of the discussion around the recent Audiobook proposal<http://lists.w3.org/Archives/Public/public-vocabs/2013Sep/0162.html> 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<http://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records> 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 Schema.org - 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 inhttp://en.wikipedia.org/Moby_Dick. 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.
>
>
>
>
>
> -- <http://www.icbl.hw.ac.uk/~philb/> <http://www.icbl.hw.ac.uk/~philb/>
>
>
> ------------------------------
>
>  Sunday Times Scottish University of the Year 2011-2013
> Top in the UK for student experience
> Fourth university in the UK and top in Scotland (National Student Survey
> 2012)
>
>  We invite research leaders and ambitious early career researchers to join
> us in leading and driving research in key inter-disciplinary themes. Please
> see www.hw.ac.uk/researchleaders for further information and how to
> apply.
>
>  Heriot-Watt University is a Scottish charity registered under charity
> number SC000278.
>