Re: Getting CreativeWork Relationships done

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:aisaac@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
>>
>>
>>
>>
>>
>>
>
>

Received on Tuesday, 11 February 2014 18:18:09 UTC