Re: Getting CreativeWork Relationships done

On the FRBR point, my [non-librarian] view is that FRBR has provided a great service in establishing a verbal vocabulary for discussing these entity relationships in the bibliographic world.  When looking at use-cases, being able to discuss the potential relationships between Work-ish things and Manifestation-y things in an understandable way is helpful.

However, translating into widely implementable technical and/or ontological solutions, appears to have been far less successful.  Unfortunately when the theory hits the road it becomes clear that sufficient real resources (or the data we have in one place about them) do not fit well into the rules of FRBR to make implementation difficult.
</OPINION>

Comments on Chaals cases:

1. Antoine is the best person to support this, but FWIW I agree with him.  A painting copy of an original painting or sculpture is a CreativeWork in its own right with its own creator, createdDate etc. this new work is a representationOf the original not the original in a different format.  Following the same principles, a photograph is a CreativeWork that is a representationOf the subject of the image - this leads me to think that the range of representationOf could be ‘Thing' so we could describe a portrait as being the representation of a Person.

2. I agree that the definition of commonEndeavour is a bit vague.  This is probably because it was designed to cover the use-case of “I know these CreativeWorks are related in some way but either I do not have the data, or there is no specific property, I can use to describe it.”   The danger being that implementers may over use it as the easy option, or not use it at all because they don’t understand its purpose.  Maybe we drop it from this round and see if the need arrises later, maybe we find a better name and description (vaguelyAssociatedWith, relatedTo, sameCoreIdeaAs, commonBasis)

3.  Yes.

4.  Agree.

Working through the examples, I am mostly in agreement - couple of comments:

I would say that  following on from {DVD,Record,Script} -> basedOn -> RJ
some of your relationships are a bit tenuous - I would expect something like this:

DVD-> exampleOfWork -> West Side Story the movie
DVD -> alternateFormat -> Netflix stream of West Side Story the movie
Record -> exampleOfWork -> West Side Story Soundtrack recording
Record -> alernateFormat -> MP3 West Side Story Soundtrack recording
Script -> alternateFormat -> Scripte braille edition.

The key to alternateFormat is that the content of work at each end of the relationship should be the same.  So the movie would almost certainly not be an alternateFormat of the book, etc.

For alternateFormat the same (reversed) triple would be applicable at each end of the relationship.


Now I have had to postpone the SchemaBibEx meeting to next week we have an opportunity to discuss it then.

I am also happy to organise/participate in a specific call to discuss this.  I could organise it for Friday this week of Monday next week.  Any takers and I’ll put up Doodle to agree a time.


~Richard

On 12 Feb 2014, at 07:45, Antoine Isaac <aisaac@few.vu.nl<mailto:aisaac@few.vu.nl>> wrote:

?  It's been around over 15 years without getting any traction and even the library community appears to be moving away from it with their new "next big thing," BIBFRAME


Itself derived from the FRBR ideas. Granted, we are pretty much all uncomfortable (to say the least) with the full FRBR model.
But it has been influential in shaping the new metadata approaches in library-land.
Probably 15 years ago almost every librarian dealing with metadata was thinking in terms of about self-contained, one-size-fits-all records. Do you think that the agreement now on more resource- and link-based models happened only because of the irresistible traction of RDF and OWL?

Now of course the question is how to get inspiration from FRBR *and* remain simple enough. Not an easy thing, especially if we have to do it over email where sub-threads like this one will prevent us from focusing on the original problem ;-)

Cheers,

Antoine




+1
Thanks,
Shlomo
Experience the all-new, singing and dancing interactive Primo brochure
-----Original Message-----
From: Antoine Isaac [mailto:aisaac@few.vu.nl]
Sent: Wednesday, February 12, 2014 01:25
To: Tom Morris
Cc: Charles McCathie Nevile; Wallis,Richard; Vicki Tardif Holland; public-schemabibex@w3.org<mailto:public-schemabibex@w3.org>
Subject: Re: Getting CreativeWork Relationships done
Hi Tom,
   Is there a group call, soon, where Chaals and a couple FRBR experts could attend?


Is FRBR the right target here?  It's been around over 15 years without getting any traction and even the library community appears to be moving away from it with their new "next big thing," BIBFRAME.
And yet most of these properties Chaals commented on are inspired by FRBR considerations. I was hoping someone with the right FRBR expertise could provide with a good wording, and especially, the clear examples.

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.

I agree with many of Chaals' points including the call for the simplification and less redundancy.
Yes, I agree too, which is why I like the idea behind 'commonEandeavour' (but I'm not found the name...) compared to the one of finding any specific property that a generic link may replace handsomely for many cases.
Finally, I agree with Dan that, in many ways, an email discussion is preferable to an ephemeral phone call.
I agree on the principle. Looking forward to seeing who will jump in and answer all of Chaal's points (some of them are not so complex, just time-consuming).
A.

Some other comments:

- I don't see where the translator's name or the date of translation gets stored.  I'm assuming that the language pair is encoded as part of the entities on either end of the link.
- I'm not sure I see why a photo of the Mona Lisa should get some special treatment as compared to a photo of a sailboat.  Aren't the Mona Lisa and the sailboat just the subjects of the creative work that is the photographic image?
- the existing CreativeWork definition is kind of a jumble.  I don't know if cleaning it up is out of scope, but things like the isBasedOnUrl property are going to clash with any new stuff in this space.

Finally, I agree with Dan that, in many ways, an email discussion is preferable to an ephemeral phone call.

Tom