Add a generic "relatedWork" property to relate CreativeWork together #1152

Open
tfrancart opened this Issue May 11, 2016 · 25 comments

9 participants

@tfrancart

It is currently possible to relate CreativeWork with :

  • hasPart / isPartOf (for physical inclusion of works)
  • workExample / exampleOfWork (for conceptual inclusion of works)
  • citation

However the model currently lacks a generic "see also" link from one CreativeWork to another, with a broad enough semantic to be used in cases not covered by the properties above.

Proposal : "relatedWork" "Indicates a somehow related CreativeWork."

@pasqLisena

The Bib Extend Group already raised the need for a better approach in defining CreativeWorks relationships (see Bib Extension wiki). They were thinking about adding more specific types of relationship (like adaptionOf, basedOn).

I am working on Doremus project which has the aim to provide a complete ontology (based on FRBRoo) for classical (and not) music (works, performances, authors, scores and so on). We are interested in proposing new properties and classes to schema.org in order to have the possibility of express some of the concepts of Doremus.

There are a lot of musical works that are related to others (apart from arrangements, for which there is the musicArrangement, there are orchestrations, variations, etc.). We where thinking about a derivativeOf property, that could be suitable also for other kind of works (e.g. movies, literatures).

Were you thinking to a specific use case for relatedWork?

@tfrancart

Specifically, our use-case is to relate legislation (considered as CreativeWork, see the proposed extension in #1156) to other texts "around" the legislation, like the debates of parliament, impact analysis, or other related documents that may be of interest for the reader. They are not derivatives, but complimentary documents.

Without going in the details of the BibEx discussions, the pragmatic idea here is to add a property with a broad semantic (but not too broad :-) ), that could then be refined with subproperties if needed.

@pasqLisena

Have you seen the isRelatedTo property? Maybe could be useful extend the domain of that one...

@mfhepp
@Dataliberate

a property with a broad semantic (but not too broad :-) )

And that, if I remember the discussion correctly was where consensus was not clear. A relatedWork property was discussed as well as having it be the super-property for workExample, isBasedOn etc.

Some felt that 'related' meant closely related enough to be able to recognise one work from the other. Others thought it could be used for all types of relationship no matter how tenuous.

There always was a desire to express exactly how two relatedWork were actually related.

I believe that the discussion eventually faded out through lack of significant use cases and examples that were not solved by the small number of specific relationship type properties. we already had or were proposing.

I agree with @mfhepp about not broadening the scope of the isRelatedTo property, however the description of the use of that property could do with refining a little to emphasis it use.

@tfrancart

We found it surprising when designing #1156 that schema.org does not include a simple and pragmatic property to deal with the "related content / work / document" use-cases such as :

  • A news article about "Panama Papers" links to related content "Panama Papers : understanding the offshore system in 3 minutes" or "Offshore, what is legal, what is not ?"
  • A movie page in IMDB links to "Related lists from IMDb users", or "Related News", or the video of the speech of the actor when receiving an Oscar;
  • A legislation page links to impact analysis documents created during the legislative process;

How would these use-cases, and especially the last one on legislation, be solved with the existing relationship properties ? or are they out of scope (of sdo) ?

@dbs

For the latter case, if the legislation has a URL (and I hope it does), then the legislation page and the impact analysis documents could all be linked by virtue of having shared schema:about properties identifying the same URL.

@pasqLisena
pasqLisena commented May 11, 2016 edited

Schema:about could also fit the first two cases (they are related because they are related to the topic).
And preliminary documents (like debates of parliament) could be specified with isBasedOn?

@tfrancart

I feel this is more than relating content because they share the same "about-ness", it is about linking content directly.
The impact analysis documents could be said to be "schema:about" the legislation... why not, but schema:about would also be used to store references to thesaurus entries classifying the content, so we would mix things.
isBasedOn is interesting, this is new, the version of sdo I was looking at was still using isBasedOnUrl. Its definition ("A resource that was used in the creation of this resource.") seems to fit with the use-case.

@unor
unor commented Jun 22, 2016 edited

FWIW for the discussion what "related" might mean, on the level of WebPage we have relatedLink:

A link related to this web page, for example to other related web pages.

@Snowbell92

sorry to revive this, but since I'm pretty new to schema markup, I thought it better to comment on an already open issue. relatedLink is for related URLs, which is good, but how to describe "related videos". the usecase is pretty similar to tfrancart's second case: a movie page (which is the mainEntityOfPage) and has a few videos that are related to it. How to explain those videos? Since related link is supposed to be URL,it doesn't properly explain the related videos (name, thumbnail etc).

@RichardWallis

We have a desire/need to somehow connect CreativeWorks together in some vague sense. It must be a vague connection because we can not identify a specific relationship that fits across use-cases.

Describing each CreativeWork as being about the same thing, probably does the job semantically, but does not satisfy the need to connect them directly in some way. Equally they could be described as isPartOf a Collection or an itemListElement in an ItemList, but that still doesn't satisfy the need being expressed here.

We also have an issue with already used property names relatedTo, isRelatedTo & relatedLink. Which are in use for Person, Product/Service, and WebPage respectively.

Pragmatically I'm thinking that those three could benefit from a generic super-property and maybe such a property could also solve the relating CreativeWorks issue we are addressing here.

That then needs a name, which brings us back to the problem we are discussing. My modelling brain suggests relatedEntity, in Schama.org speak that would translate to relatedThing. Some of my library community friends would possibly suggest seeAlso as a suitable name. Any or each of these having a range of Thing.

What do others vaguely think?

@thadguidry
thadguidry commented Jul 19, 2016 edited

@Snowbell92 " a movie page (which is the mainEntityOfPage) and has a few videos that are related to it. "

Can you describe further the relatedness of the videos back to the movie ? Are those videos related to the movie by sharing the same subject, the movie itself ? or sharing other subjects , specific or general like Global Warming, Apple iPhone, Home Gardening , Walmart ? or sharing something else ? Let's avoid the use of related...and instead actually attempt to describe the "relation" a bit more. Instead of saying "these are related", instead say "these share the same BLAH BLAH BLAH".

@RichardWallis I dislike the use of "related" in property names...it does not describe the "relation" further. Let's try to describe the relation. Also, isRelatedTo is already broad enough, its the wild west of relationships and can connect any 2 Things already in Schema.org but rear no significant idea of the connection or why...but just that they are connected somehow. Further allowing to define that "HOW" is the key to all the "relationship" Properties....that's really all that is left to be done, IMHO.

@Snowbell92
Snowbell92 commented Jul 20, 2016 edited

@thadguidry those videos are related to the movie itself. An example is like this: I have a movie "Black" and in the page of this movie, I also have the trailer for the movie, the music videos from this movie and if it has won any awards etc - the acceptance speech video. This is my use case. This use case is pretty impossible to describe by relation - unless we have a blanket property, because they are related through the mainEntityOfPage. And in case of trailer or acceptance speeches, isPartOf is no help either.

I also have videos that are related to each other through one of their artists (like Hugh Grant's Notting Hill and Three Weddings and a Funeral). relatedTo is not useful for ovious reason - these are not persons.

Another case is most popular videos from the same category. The use case is like this : I have a pop music video that has been viewed 1 million time - and I would like to show other videos that has been viewed around the same number too. This case is fairly common among websites that primarily deal with videos - YouTube does this in their suggestions box. I suppose relatedLink can be used here, except then I am only able to specify the URLs and not much else.

and isn't isRelatedTo used for products? what happens if I don't have products ? again, my use case, the movies aren't products, we aren't selling those.

@RichardWallis I like the idea of having a relatedThing or relatedEntity, mainly because I would like to describe my related entities properly without involving list in it. But I wonder if extending Collection to include all types of CreativeWorks may solve our problem or not. What do you think about that? or does that create more semantics problem?

@RichardWallis

@Snowbell92 Firstly Collection is already broad enough for the particular need you describe: "A created collection of Creative Works or other artefacts.".

Secondly most of the relationships you describe are covered by current Schema.org constructs:

I still believe that there is potential for a super-property for the established 'related' oriented properties that could be used generically if needed. However it does also raise a concern that such a property would be abused as a shortcut to not fully describing relationships where possible, as above.

@thadguidry I share your dislike of 'related' in property names but struggle to come up with an alternative.

@Snowbell92
Snowbell92 commented Jul 20, 2016 edited

@RichardWallis please correct me if I'm wrong, but collection is a bibliographic extension, is it not? then it should only be relate to books and such, that is, written material, right? if it were core - I think it would solve my problems.

I take your point about trailers and music videos. I also take your point about abusing the related super property, but it is still needed - I think - mainly to relate other videos that share noting but a category, in my case.

@Snowbell92
Snowbell92 commented Jul 20, 2016 edited

I deleted the sentence below from my previous comment, because I am still sufficiently confused.

@RichardWallis about the award acceptance video - is this code below valid? because this is the relationship I'm after :

{  "@context": "http://schema.org",
  "@type": "Movie",
  "name": "Footloose",
  "awards" : [{
        "@type" : "text",
        "award" : "VMA",
        "about" : {
            "@type" : "videoObject",
            "name" : "award video"
            }
  }]
}
@RichardWallis

@Snowbell92 Collection was introduced as a extension proposal by the bibliographic community, but like all other terms in the core, and extensions to, Schema.org are applicable wherever their description makes them applicable. So "A created collection of Creative Works [or subtypes of CreativeWork] or other artefacts."

@RichardWallis

@Snowbell92 You have the about relationship the wrong way around - the speech is 'about' the movie/award.

Give me a short time and I will come back with an example

~Richard.

@thadguidry
thadguidry commented Jul 20, 2016 edited

@Snowbell92 if they share nothing but a category ? ... then that is still where you can just use http://schema.org/about to handle this concern for a category or subject. So we have you covered there also.

@RichardWallis Can't just make a bucket....you gotta describe the bucket to know if things can fit well into it or not....so again.... lets avoid 'related' and even creating a superproperty around it.....there really is no need I have seen yet at all. So until someone has shown me the need....let's avoid adding a superproperty for 'related' that will be just an indescribably empty bucket.

All - again, anytime we think or use the term 'related' in some fashion... I urge everyone to spin that thought around instead, and think ... 'they share BLAH' and then see what existing Schema.org properties help you describe WHAT they share. (knowing that we do not have a way to say that HOW 2 things share that WHAT... but that might be a useful new subproperty to discuss in another issue)

@RichardWallis

@Snowbell92 After a bit longer (short) time than I hoped, I finaly got around to producing the promised example. See below.

It describes a WebPage, which is focused on a Movie entity, which is also part of a Collection of entities that are either about or isBasedOn that movie.

Like all examples in this area, the more entities described the more the process tends towards art rather than science. So this is only one way that this could be represented. Also In real life, the data would greatly benefit from the liberal application of actor, director, duration, sameAs, genre, etc. properties. Also the relationship between the VMA Awards Event, the speech and who delivered it, could be beneficially described - but this is only an example!

~Richard.

{  "@context": "http://schema.org",
    "@graph":[
    {
        "@type": "WebPage",
        "@id": "http://movies.example.com/footloose.html",
        "name": "Footloose",
        "mainEntity": "_:m1"

    },
    {
        "@type": "Movie",
        "@id": "_:m1",
        "sameAs": "imdb.com/title/tt0087277/",
        "name": "Footloose",
        "award":"VMA",
        "isPartOf": "_:c1",
        "mainEntityOfPage": "http://movies.example.com/footloose.html"
    },
    {
        "@type":"Movie",
        "@id": "_:m2",
        "name": "Footloose: The Trailer",
        "about": "_:m1",
        "isBasedOn": "_:m1",
        "exampleOfWork": "_:m1",
        "isPartOf": "_:c1"
    },
    {
        "@type":"MusicVideoObject",
        "@id": "_:mv1",
        "name": "Footloose Music Video",
        "about": "_:m1",
        "isBasedOn": "_:m1",
        "isPartOf": "_:c1"
    },
    {
        "@type":"videoObject",
        "@id": "_:v1",
        "name": "Acceptance speech for VMA Award for Footloose",
        "about": "_:m1",
        "about": "VMA",
        "isPartOf": "_:c1"
    },
    {
        "@type": "Collection",
        "@id": "_:c1",
        "name": "Footloose and related items",
        "hasPart": "_:m1",
        "hasPart": "_:m2",
        "hasPart": "_:mv1",
        "hasPart": "_:v1"
    }
    ]
}
@thadguidry
thadguidry commented Jul 22, 2016 edited

@RichardWallis Careful there. If we are going with the strict definition of what we have...then that would be that isBasedOn can also be called "usedBy". Re-read the definition:

A resource that was used in the creation of this resource. This term can be repeated for multiple sources. For example, http://example.com/great-multiplication-intro.html.

@Snowbell92 I personally would remove the isBasedOn for the Movie Trailer and the MusicVideoObject. The reason is that isBasedOn kind of establishes a "base" work that an adaptation or derivative used as a basis. That's not correct in the case of the Movie Trailer or MusicVideoObject.

UPDATE: well, maybe it is correct, but instead just simple about holds the truth of how each of them has content where the subject is the Movie.

But then if you agree with the definition we have for isBasedOn and think both the Trailer and the MusicVideoObject are "using" or "used" the Movie in their creation, Then go with what @RichardWallis has suggested.

@RichardWallis

As I said this is where 'art' or interpretation starts to come into play.

From my point of view the contents of a trailer, or an [extracted from the film] music video, are created from the contents of the movie itself hence based on its content.

But I am no movie metadata expert, so...

@thadguidry
thadguidry commented Jul 22, 2016 edited

@RichardWallis I'm just wondering now if we picked the completely wrong definition against the property name ? "Is Based On" does not equate to its current definition. But we have always said...use the property description to build things... not just our sometimes quirky property names....so I dunno. Do we have the ability to retroactively change this ??

Yikes ! look at this... this property has the same definition https://schema.org/isBasedOnUrl
Did we mix some definitions somewhere along the lines between 2.0 and 3.1 ?
UPDATE: ah, that's a superseded property. Ignore Yikes.

I also think we should absorb the UsedBy and Uses properties that Wikidata created recently.
#1258 usedBy and uses have landed into Wikidata and we should have them also

@RichardWallis
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment