- From: Antoine Isaac <aisaac@few.vu.nl>
- Date: Wed, 12 Feb 2014 00:24:59 +0100
- To: Tom Morris <tfmorris@gmail.com>
- CC: Charles McCathie Nevile <chaals@yandex-team.ru>, "Wallis,Richard" <Richard.Wallis@oclc.org>, Vicki Tardif Holland <vtardif@google.com>, "public-schemabibex@w3.org" <public-schemabibex@w3.org>
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
Received on Tuesday, 11 February 2014 23:25:28 UTC