Re: Getting CreativeWork Relationships done

The wiki says we have a call tomorrow:
http://www.w3.org/community/schemabibex/wiki/Meet_20140212 !

That said, I'm wary about trying to cover too much new ground during a
call: it rules out the deep reflection and research when new issues are
brought up, reduces participation to those who are actually able to be
there at a given point and time, and is harder to go back and revisit the
logic that lead to a given decision (whereas long email threads at least
let newcomers catch up on all of the angles that were considered along the
way, and email is a lot easier to scan than audio recordings).

Detailed post-call summaries available shortly after the call would help
alleviate this concern, though.


On Tue, Feb 11, 2014 at 12:39 PM, Antoine Isaac <aisaac@few.vu.nl> wrote:

> Hi,
>
> Is there a group call, soon, where Chaals and a couple FRBR experts could
> attend?
>
> I believe Chaals' "ah-ha" moment :-) brings him quite close to what we
> intended, and we should be able to produce a piece of documentation that
> answers his questions, even before the "ah-ha" moment.
>
> But it would be so much more efficient to discuss it live than having
> yet-another email discussion on FRBR!
> Actually I'd be glad to answer, but I know that this won't be the last
> email, and others will chime in, and I won't have the bandwidth, while
> everything might be fixed in an hour of good talk.
>
> Cheers,
>
> Antoine
>
>
> On 2/10/14 12:42 PM, Charles McCathie Nevile wrote:
>
>> On Sun, 09 Feb 2014 04:37:03 +0400, Wallis,Richard <
>> Richard.Wallis@oclc.org> wrote:
>>
>>  I have now updated CreativeWork Relationships<https://www.w3.
>>> org/community/schemabibex/wiki/Schema_CreativeWork_Relationships> page
>>> to reflect some discussions, expand some property descriptions, and added
>>> some supporting notes.
>>>
>>> Hopefully this will help move things forward.
>>>
>>
>> It certainly clarifies things, but I am still getting confused when I try
>> to work through examples.
>>
>>  Chaals, I believe that ‘alternateFormat’ has the potential to cover the
>>> potential conflict between the Access and Literary focussed folks around
>>> the use of the term adaption.
>>>
>>
>> I don't think we're going to end up with a lot of conflict. The need is
>> to describe whether something is intended to be as literal a rendering as
>> possible in a different format or medium, or whether it is intended to
>> adapt a work to a particular format without fundamentally changing it. It
>> seems the two work out OK in that sense, except alternativeFormat then
>> makes representationOf redundant as I understand it.
>>
>> I'm not sure what the scope of commonEndeavour is,and therefore unclear
>> if it is useful in its own right, or is just a bidirectional version of
>> workExample/exampleOfWork.
>>
>> This leaves me thinking that we should
>> 1. Remove representationOf, and add the idea of a photo of a picture to
>> the things that would be covered by alternateFormat.
>> 2. Clarify what we mean by commonEndeavour (IMHO that it is a very broad
>> term…) or remove it.
>> 3. Make the descriptions really clear, especially about which direction
>> the relationship goes.
>> 4. Declare victory and ask schema.org to figure out how to deal with the
>> issue of adding inverse properties then publish it.
>>
>> The following is my working through an example.
>>
>> Although it's only one taken from the existing descriptions, I mentally
>> compared it to:
>> + "differential calculus",
>> + "the Bible",
>> + "Never Gonna Give You Up" (a song used in the weird habit of
>> rick-rolling, qv),
>> + "Mona Lisa" (the famous painting known by that name),
>> + http://xkcd.com/386,
>> + this set of terms itself.
>> It *seems to me* that my conclusions hold for at least that set of
>> creative works.
>>
>> Let's start with the premise that "Romeo and Juliet" is a Creative Work
>> and call it RJ
>>
>> An e-book edition of the script of "Romeo and Juliet" is a Creative Work
>> - lets call it eBk1
>>
>> A performance of "Romeo and Juliet" at my local theatre is also a
>> Creative Work - lat's call it Play1
>>
>> A broadcast of the movie "Romeo and Juliet" (the 1996 Baz Luhrman
>> version, which uses "the original text") is also a Creative Work - let's
>> call it Baz.
>>
>> We can then say
>> {eBk1, Baz, Play1} -> CommonEndeavour -> {eBk1, Baz, Play1}
>> right? This seems clear, and the use case I can see is for listing
>> "related items" without forcing anyone to do tree traversal. So far, so
>> good.
>>
>> I *think* we can say
>> {eBk1, Baz, Play1} -> exampleOfWork -> RJ
>> RJ -> workExample -> {eBk1, Baz, Play1}
>> but to be honest I am not 100% clear if the relationship goes this way or
>> the other way. That's just a question of being clearer in the documentation
>> - perhaps putting a simple text example in directly.
>>
>> What I am totally unclear about is which is an alternateFormat, which is
>> an adaptation, and which is a representation. I could happily justify
>> choosing adaptation or representation at will, as relationships in the form
>>
>> {eBk1, Baz, Play1} -> representationOf -> {eBk1, Baz, Play1, RJ}
>>
>> And here I reach 2 "Ah-Ha" moments. It seems that maybe alternateFormat
>> implies not changing the *literal* content, just trying to present it as
>> faithfully as possible in a "different" medium, whereas adaptationOf means
>> presenting the content in a form appropriate to the medium. With
>> representationOf being an ambiguous amalgam of these two possibilities.
>>
>> So it seems fair to say
>> Baz -> adaptationOf -> {eBk1, RJ}
>>
>> and
>> Play1 -> alternateFormat -> eBk1
>>
>> Meanwhile, I also have a DVD of West Side Story ("DVD"), a Vinyl Record
>> of the original Broadway Cast performing it ("Record") and a script, that
>> amounts to a musical score with stage directions and interstitial
>> conversation ("score").
>>
>> So I can say
>> {DVD, Record, Script} -> basedOn -> RJ
>>
>> and
>> {DVD, Record} -> adaptationOf -> Script
>>
>> can I say
>> Script -> alternateFormat -> DVD
>> (and vice versa)?
>>
>> What about
>> {Script, DVD, eBk1} -> commonEndeavour -> {RJ, Play1, Baz}
>> or are the different forms of West Side Story only commonEndeavour for
>> each other?
>>
>> I've probably still forgotten something. I'm also wary of seeking a level
>> of perfection that is unattainable. But I'd love someone to confirm they've
>> worked through the actual terms we have on some examples…
>>
>> cheers
>>
>> Chaals
>>
>>  ~Richard
>>>
>>> On 7 Feb 2014, at 12:02, Wallis,Richard <Richard.Wallis@oclc.org<mailto:
>>> Richard.Wallis@oclc.org>> wrote:
>>>
>>> Hi Chaals,
>>>
>>> Coincidentally, and sharing your desire to move this forward, I had
>>> started to focus on this a couple of days ago.
>>>
>>> As the original page was basically a list of suggestions collected from
>>> various places there are several not well described and in some cases
>>> duplicate or conflicting suggestions.
>>>
>>> I am in the process of simplifying the list and hopefully adding some
>>> description of uses to the page.
>>>
>>> My personal opinion is that we could gain benefit from going with a
>>> reduced simplified set for now, leaving things open for future CreativeWork
>>> relationship property proposals supported by compelling use cases.
>>>
>>> In general terms I agree that inverse properties are not ideal.
>>>  However, there are certain situations on the web where a webmaster will
>>> not have both sides of a relationship in their domain thus making inference
>>> about inverse relationships difficult if not impossible.
>>>
>>> Hopefully I will have time today to complete my update to the page.
>>>
>>> I’ll let you know when I have, and we can continue the discussion.
>>>
>>> ~Richard
>>>
>>> On 6 Feb 2014, at 21:53, Antoine Isaac <aisaac@few.vu.nl<mailto:aisaa
>>> c@few.vu.nl>> wrote:
>>>
>>> Hi Chaals,
>>>
>>> Some very reasonable points in your mail.
>>>
>>> I'm very much in favour of dropping the inverse. Actually I think it's
>>> the view on many people. But this page has been left aside from the most
>>> recent discussions (thanks for mentioning it again!).
>>>
>>> Actually the number of relations is not so big, once we remove the
>>> inverses.
>>>
>>> But one issue is indeed that the definition do not differentiate enough
>>> these properties to make them sound interesting enough. We're all
>>> more-or-less familiar with these notions in the group, so we might be less
>>> demanding than we should--we know the stuff, after all.
>>>
>>> Decision-making on whether to keep some properties or not may be helped
>>> by mentioning the links between these properties, when there are any. E.g
>>> in pseudo-maths:
>>> workExample o exampleOfWork -> commonEndeavour
>>> isFormatOf U hasFormat -> alternateFormat
>>> The 'more general' properties are intended for these many cases where
>>> the theoretically-shining, more specific properties cannot be used because
>>> the data at hand is just not granular enough.
>>>
>>> On the representation question. I'll try a complete example, even though
>>> my FRBR skills are a bit rusty...
>>> Let's imagine you take a picture of a statue that happens to be a cast
>>> of the Thinker by Rodin. The photo is a representation of an example of the
>>> work "Thinker", where the latter is meant as an abstract thing (the concept
>>> of the Thinker as Rodin thought it even before making the first instance).
>>> Perhaps one could say that the picture is also a representation of the
>>> abstract work too. But others would disagree: i.e. your picture could also
>>> "represent" a dog having a pee on the sculpture's pedestal, the "example"
>>> is supposed to be respecting the original intention of the work better.
>>>
>>> This is of course important in the publishing industry, where
>>> re-printing a book is clearly different from taking a picture of its cover.
>>>
>>> Cheers,
>>>
>>> Antoine
>>>
>>> On 2/6/14 9:05 PM, Charles McCathie Nevile wrote:
>>> Hi all,
>>>
>>> I'd really like to get this wrapped up and into schema.org<
>>> http://schema.org> - in my case because we would really like to have it
>>> for accessibility, but also because I think it's generally useful.
>>>
>>> So my general comment on http://www.w3.org/community/
>>> schemabibex/wiki/Schema_CreativeWork_Relationships is that we still
>>> have too many types, whose semantics are not sufficiently distinct to
>>> survive contact with "the enemy"^W^W normal webmasters trying to use them…
>>>
>>> To be specific:
>>>
>>> -Inverse Properties
>>>
>>> I'd prefer not to have inverse properties for everything. They make
>>> schema.org<http://schema.org> twice as big, and make translation
>>> complicated. But that's a schema-wide problem. If anyone has a sense of how
>>> to deal with it that would be welcome. RDFa and JSON-LD can handle
>>> inverses, but microdata cannot easily. There are complex ways to structure
>>> microdata using itemref, but they will destroy the original goal of making
>>> it easy to write stuff, then mark up its semantics as needed because they
>>> make heavy requiremnts on the way things are written to start with. An
>>> alternative is to mint a general rev- prefix, or -inv suffix, or something,
>>> but that isn't obviously attractive either.
>>>
>>> -WorkExample / exampleOfWork vs Format*
>>>
>>> These seem to me mostly the same thing. There are already media types
>>> for works, so if it matters it seems that the format can be derived - and
>>> if it isn't obvious why it matters then it isn't clear to me whether the
>>> difference is obvious to someone trying to mark it up.
>>>
>>> -BasedOn/Adaptation/Version
>>>
>>> These seem redundant. One clue is the current description of isVersionOf
>>> says "adaptation" in its description. Is West Side Story a version or
>>> adaptation of Romeo and Juliet? I suggest collapsing these two categories.
>>>
>>> -Translation
>>>
>>> These seem straightforward. But I think it would make sense to
>>> explicitly say that they are in a different language. One of the "false
>>> friends" that catches russian speakers is that "translation" means a
>>> broadcast - and while they probably pick the difference more often reading
>>> than writing, it would be helpful to clarify.
>>>
>>> -isRepresentationOf
>>>
>>> I can't understand how this is distinctive. If I take a photo of a
>>> sculpture I see in the park, would I mark it as a Representation, or
>>> exampleOf…? What do we lose if we drop this property? It seems to me that
>>> doing so would mean we gain in reducing the complication of some people
>>> choosing one and some people choosing another.
>>>
>>> Thoughts, brickbats, requests for the phone number of my boss?
>>>
>>> cheers
>>>
>>> Chaals
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>