Re: Getting CreativeWork Relationships done

Hi Chaals,

Coincidentally, and sharing your desire to move this forward, I had started to focus on this a couple of days ago.

As the original page was basically a list of suggestions collected from various places there are several not well described and in some cases duplicate or conflicting suggestions.

I am in the process of simplifying the list and hopefully adding some description of uses to the page.

My personal opinion is that we could gain benefit from going with a reduced simplified set for now, leaving things open for future CreativeWork relationship property proposals supported by compelling use cases.

In general terms I agree that inverse properties are not ideal.  However, there are certain situations on the web where a webmaster will not have both sides of a relationship in their domain thus making inference about inverse relationships difficult if not impossible.  

Hopefully I will have time today to complete my update to the page.

I’ll let you know when I have, and we can continue the discussion.

~Richard

On 6 Feb 2014, at 21:53, Antoine Isaac <aisaac@few.vu.nl> wrote:

> Hi Chaals,
> 
> Some very reasonable points in your mail.
> 
> I'm very much in favour of dropping the inverse. Actually I think it's the view on many people. But this page has been left aside from the most recent discussions (thanks for mentioning it again!).
> 
> Actually the number of relations is not so big, once we remove the inverses.
> 
> But one issue is indeed that the definition do not differentiate enough these properties to make them sound interesting enough. We're all more-or-less familiar with these notions in the group, so we might be less demanding than we should--we know the stuff, after all.
> 
> Decision-making on whether to keep some properties or not may be helped by mentioning the links between these properties, when there are any. E.g in pseudo-maths:
> workExample o exampleOfWork -> commonEndeavour
> isFormatOf U hasFormat -> alternateFormat
> The 'more general' properties are intended for these many cases where the theoretically-shining, more specific properties cannot be used because the data at hand is just not granular enough.
> 
> On the representation question. I'll try a complete example, even though my FRBR skills are a bit rusty...
> Let's imagine you take a picture of a statue that happens to be a cast of the Thinker by Rodin. The photo is a representation of an example of the work "Thinker", where the latter is meant as an abstract thing (the concept of the Thinker as Rodin thought it even before making the first instance).
> Perhaps one could say that the picture is also a representation of the abstract work too. But others would disagree: i.e. your picture could also "represent" a dog having a pee on the sculpture's pedestal, the "example" is supposed to be respecting the original intention of the work better.
> 
> This is of course important in the publishing industry, where re-printing a book is clearly different from taking a picture of its cover.
> 
> Cheers,
> 
> Antoine
> 
> On 2/6/14 9:05 PM, Charles McCathie Nevile wrote:
>> Hi all,
>> 
>> I'd really like to get this wrapped up and into schema.org - in my case because we would really like to have it for accessibility, but also because I think it's generally useful.
>> 
>> So my general comment on http://www.w3.org/community/schemabibex/wiki/Schema_CreativeWork_Relationships is that we still have too many types, whose semantics are not sufficiently distinct to survive contact with "the enemy"^W^W normal webmasters trying to use them…
>> 
>> To be specific:
>> 
>> -Inverse Properties
>> 
>> I'd prefer not to have inverse properties for everything. They make schema.org twice as big, and make translation complicated. But that's a schema-wide problem. If anyone has a sense of how to deal with it that would be welcome. RDFa and JSON-LD can handle inverses, but microdata cannot easily. There are complex ways to structure microdata using itemref, but they will destroy the original goal of making it easy to write stuff, then mark up its semantics as needed because they make heavy requiremnts on the way things are written to start with. An alternative is to mint a general rev- prefix, or -inv suffix, or something, but that isn't obviously attractive either.
>> 
>> -WorkExample / exampleOfWork vs Format*
>> 
>> These seem to me mostly the same thing. There are already media types for works, so if it matters it seems that the format can be derived - and if it isn't obvious why it matters then it isn't clear to me whether the difference is obvious to someone trying to mark it up.
>> 
>> -BasedOn/Adaptation/Version
>> 
>> These seem redundant. One clue is the current description of isVersionOf says "adaptation" in its description. Is West Side Story a version or adaptation of Romeo and Juliet? I suggest collapsing these two categories.
>> 
>> -Translation
>> 
>> These seem straightforward. But I think it would make sense to explicitly say that they are in a different language. One of the "false friends" that catches russian speakers is that "translation" means a broadcast - and while they probably pick the difference more often reading than writing, it would be helpful to clarify.
>> 
>> -isRepresentationOf
>> 
>> I can't understand how this is distinctive. If I take a photo of a sculpture I see in the park, would I mark it as a Representation, or exampleOf…? What do we lose if we drop this property? It seems to me that doing so would mean we gain in reducing the complication of some people choosing one and some people choosing another.
>> 
>> Thoughts, brickbats, requests for the phone number of my boss?
>> 
>> cheers
>> 
>> Chaals
>> 
>

Received on Friday, 7 February 2014 12:02:52 UTC