Re: Getting CreativeWork Relationships done

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.

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

Received on Wednesday, 12 February 2014 00:06:48 UTC