Re: CreativeWork relationships

What worries me about the "isBasedOn" is that it assumes a precedence, 
and I'm not sure that it will always be clear to the person doing the 
coding which thing precedes the other.

Admittedly, I live in a country where a large percentage of the 
population can't find Afghanistan on a map, but even in the best of 
cases, how many people can identify the original work that Black Orpheus 
[1] is derived from, or which one came first, 7 Samurai or The 
Magnificent 7? [2]

This is why I prefer a "relator" property that does not require such a 
decision.

kc


[1] https://en.wikipedia.org/wiki/Black_Orpheus
[2] https://en.wikipedia.org/wiki/The_Magnificent_Seven

On 9/20/13 4:55 PM, Niklas Lindström wrote:
> Hi Phil,
>
> On Fri, Sep 20, 2013 at 4:28 PM, Phil Barker <phil.barker@hw.ac.uk
> <mailto: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 <http://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)
>     <http://en.wikipedia.org/wiki/Macbeth_%28character%29> 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 <http://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
>     <http://www.hw.ac.uk/researchleaders> for further information and
>     how to apply.
>
>     Heriot-Watt University is a Scottish charity registered under
>     charity number SC000278.
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet

Received on Saturday, 21 September 2013 12:06:53 UTC