Re: Getting CreativeWork Relationships done

You're referring to a very different (and much more complicated and human
intensive) component of FRBR: adaptations, translations, supplements, etc.
 commonEndeavour is intended to smooth over different versions of the
_same_ work (that is, the various printed forms of 'Adventures of
Huckleberry Finn', but it wouldn't generally be used to link to a stage or
screen adaptation, for example) as opposed to related works.  We have a lot
of data that we know is referring to the same general intellectual output,
but we do not necessarily know the direct relationship between the
individual representations of it, nor do most people care (they just care
about the work, in general).

-Ross.


On Wed, Feb 12, 2014 at 2:55 PM, Tom Morris <tfmorris@gmail.com> wrote:

> On Tue, Feb 11, 2014 at 6:24 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:
>
>>
>>> I've looked at the "common endeavor" a few times and have never been
>>> able to associate it in my mind with a real world concept that I'm familiar
>>> with.  I know about books being revised with new editions, translated into
>>> other languages, adapted for the stage, those plays being performed, the
>>> performances being filmed, screenplays being written using the original
>>> story, etc, but common endeavor?  It seems to add complexity without any
>>> additional value.
>>>
>>
>> So better have specific relations for your 6 cases? I have doubts,
>> especially considering that in many cases the data needed to elicit a
>> specific relation just won't be available. These links could be instead
>> produced by automatic techniques, which may only be able just to find a
>> generic link. (well, if you have an algo that produce your on top of
>> existing records, please send it around!) And of coruse most users don't
>> really care: as long as it's derived from the same work, and it has the
>> right format (text, video), it may be interesting, say, for Amazon-like
>> scenarios.
>
>
> This sounds like it's drifting towards an isRelatedTo property where the
> nature of the relationship is undefined.  Creative works can be
> automatically clustered in all kinds of ways, but the engines that do that
> type of work won't be wanting to express the results in schema.orgvocabularies, in my opinion.
>
> Yes, I favor specific properties and I don't think there are that many of
> them to cover the popular relationships that we describe in prose.
>  Adaptation, translation, work/edition, and subject cover the vast majority
> of the common cases.  I think commonEndeavor should be deleted.
>
> I'll try to find some time to work through Chaals' examples, but in the
> mean time it might be instructive to browse the various topics here:
>
>   https://www.freebase.com/search?query=Romeo+and+Juliet
>
> and see how they are connected together.  Obviously the Freebase schema is
> more detailed than is appropriate for schema.org, but I think a lot of
> the basics apply.  In particular, they've gotten a huge amount of mileage
> out of an adaptionOf property applied to all different types of media.
>
> The biggest point for me is that it the properties don't match the (human)
> vocabulary that we use to talk about this stuff, it will be harder to
> understand and less likely to be used.  If you look at West Side Story<https://www.freebase.com/m/085xh> is
> has a specific relationship to Shakespeare's Romeo & Juliet, its own film
> adaptations, DVDs of films, sound tracks, etc.  If you read the Wikipedia
> articles, you'll see a very common vocabulary used to describe all these
> relationships.
>
> Tom
>
>