Re: Getting CreativeWork Relationships done

On Tue, Feb 11, 2014 at 4:06 PM, Charles McCathie Nevile <
chaals@yandex-team.ru> wrote:

> On Wed, 12 Feb 2014 03:24:59 +0400, Antoine Isaac <aisaac@few.vu.nl>
> wrote:
>
>  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 certainly understand that this comes from FRBR, and I expect someone
> with a good FRBR background would be good to talk to about it. I might look
> at the local library school (University Carlos III, Madrid) for such a
> person.
>
> But my main concern here is to adapt the ideas that FRBR set down to
> something that will withstand (ab)use from a community who generally don't
> know why library schools exist.


This is a common and understandable refrain, but surely you don't need to
be deeply versed in information science to see that two things that are not
the same (whether they're written in different languages, or have different
introductions, or whatever) should not be treated sameAs?

I don't really care if commonEndeavour is what's used, but there needs to
be some way to say that two things are generally referring to the same
platonic ideal, even if they are quite different in reality.

FRBR is kind of a red herring here, although it's useful shorthand to
describe what's going on.  It could be commonWork or
commonIntellectualProperty or something.  I think people can grasp the
concept without needing to resort to FRBR.

-Ross.

>
>
>  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.
>>>
>>
> That one makes sense to me in a web world, as "What's Related?" -
> describing things that are on the same topic, rather than things that were
> often bought in the same set of purchases.
>
> But unless it replaces some of the other properties, I think its
> justification for being there is pretty weak.
>
> Although it often isn't clear, almost everyone I have asked in regards to
> schema.org seems to believe that it is important to identify the original
> work which has been adapted. I personally believe that is only occasionally
> important and maybe equally as often is either impossible or pointless -
> both of which cases make the effort counter-productive. commonEndeavour is
> the only property that allows for a statement that doesn't try to imply a
> directionality of the "adaptation", and for taht reason I think it is worth
> thinking carefully before dropping it.
>
>
>   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 think we do... Or at least for most of them.
>
>
>  I have doubts, especially considering that in many cases the data
>> needed to elicit a specific relation just won't be available.
>>
>
> Right.
>
>
>  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.
>>
>
> Right...
>
>
>  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.
>>
>
> I'm happy to try to find time to talk to someone who wants to spend it.
> But that will be difficult in practice, and I strongly agree that an
> unrecorded conversation is less helpful than an archived email thread.
>
>
>  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).
>>
>
> Right. If we're lucky, none of them are complex.
>
> One exercise that I think would be really helpful is for people to take
> examples (I offered a list...) and work through them, explaining their
> thinking. That makes it pretty easy to compare apples with apples, and as
> easy as it can be to think about what someone who is in a hurry and has no
> real training in this area will do in practice.
>
> As I said at the top, my goal isn't in any way to even enter the
> discussions around FRBR or dispute that it does a reasonable job of
> codifying complex information in a way that maintains it.
>
> I'm just looking to get a useful subset into schema.org ASAP, that
> maximises the real information recorded. Which requires minimising the
> likelihood of amateurs getting it wrong so often that they pollute the
> dataset to the point where the schema becomes unreliable...
>
>
>  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 think the translator name and the date is like generic author
> information and not a problem we have to solve here (if there isn't a way
> to add that in schema.org then it does have to be solved...)
>
>
>  - 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?
>>>
>>
> Yeah, this is sort of what I was thinking - except that when we are mostly
> talking about representations, it can be assumed. The Mona Lisa (the bit of
> wood and canvas and stuff) cannot be downloaded from the Web, and no Web
> resource is the actual painting. Whether a Web Resource is really Romeo and
> Juliet, or a representation, is a question that seems far too deep to offer
> a practical and usable solution.
>
>
>  - 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.
>>>
>>
> It is a mess. I think cleaning it up might be out of scope of the work on
> relationships - and is unnecessary to get some useful relationship stuff
> into schema.org - but if someone has suggestions...
>
> cheers, and thanks all for the discussion - so far it is helpful.
>
>
> chaals
>
> --
> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>       chaals@yandex-team.ru         Find more at http://yandex.com
>
>