Add a generic "relatedWork" property to relate CreativeWork together

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

please don't!
this is for relating products to products with a very special meaning.

---

martin hepp
www: http://www.heppnetz.de/
email: mhepp@computer.org

Am 11.05.2016 um 15:03 schrieb Pasquale Lisena notifications@github.com:

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

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

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

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]

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]

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