Re: Getting CreativeWork Relationships done

> ?  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
> 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

Received on Wednesday, 12 February 2014 07:46:01 UTC