Use schema:Thing as domain/range of isPartOf

[acka47]

I just noticed that isPartOf names Creative Work as expected values and as types used on. The list of sub-properties includes partOfOrder, though, which is expected to be used on resources of type ParcelDelivery with expected value Order. Both are Intangibles.

Thus, I propose to change the domain and range of isPartOf to Thing. When doing this, the domain/range of hasPart should probably be adjusted as well.

[Dataliberate]

At first glance the basic proposal of having Thing in the range of isPartOf
that raises a +1 from me.

However if you follow the logic of the associated consequences, some of
which you reference, brings you to the inevitable conclusion that we should
change the domain and range for both isPartOf and hasPart to be Thing.

From a usefulness point of view, that is something I am also inclined to
support. However in the spirit of the concerns about hanging too many
properties on Thing, we should look for a broad consensus on it.

[vholland]

Do we have a use case for this change? I hesitate to make such a large change without a compelling use case.

[jaygray0919]

We would like to use schema.org to define foods. Currently, we define a food using Class and Thing. We would like to say Food hasPart chemical (a Thing) and commodity (a Thing). Because these Things are not a CreativeWork we are not able to specify the hasPart and isPartOf relationships for our defined Things. the @acka47 proposal would enable our use case.

[acka47]

Do we have a use case for this change?

The use case I was working on when realizing this inconsistency is relating a record – which normally is not considered to be a creative work – to the dataset it comes from: hbz/lobid-organisations#128 (comment). In this particular case it is quite probable, though, that we will end up describing the relation in some other way e.g. using the PROV Ontology. However, this probably might not be the kind of use case a lot of schema.org users face...

[danbri]

In prior discussion in #436 and elsewhere we have generally decided not to do this. There are so many different senses of "part" that can overlap and be confused if we broaden the property - e.g. see http://plato.stanford.edu/entries/mereology/

My proposal would be to define dedicated properties for specific use cases e.g. for food we might have containsChemical, for places we already have containsPlace, for people who are "part of" organizations we have already got "affiliation", and for sub-events within a larger/longer containing event, we already have subEvent.

As we move to having more domain-oriented extensions e.g. medicine, finance I think we'll see a desire to have more precise definitions. What are the "parts" of a medical Patient? (to a GP, to a neuroscientist, to an anesthetist, to a psychiatrist, to a roboticist fitting a prosthetic limb, ...) or of a bank account? of a book? TV Series? I fear that overloading "isPartOf" for all of these will lead to a kind of grey goo :) It's hard enough to be clear even for CreativeWork, and the work around EventSeries #447 shows these things to be differently subtle and tricky in each new area.

What we could do is create some navigational structure (e.g. supported at the schema level using subtypes of Property or a superproperty hiearchy) which allows these part-esque properties to be seen more clearly.

[acka47]

The approach outlined by @danbri sounds reasonable to me. I think the inconsistency should be resolved in another way then. In this mail some part-whole-relations in schema.org are listed that are not sub-properties of isPartOf as they don't refer to part-whole-relationships of creative works. For the sake of consistency, I suggest to stop listing partOfSystem and partOfOrder as subproperties of isPartOf as they also don't apply to creative works.

[jaygray0919]

OK, we understand the @danbri logic. Currently, we use relevant schema.org terms in one graph, and then use a second graph for domain-specific ontologies such as Plant Ontology. So, with schema.org, we can declare the basics (name, Class, Thing), and then declare complementary, domain-specific, objects and relationships in a second graph. The "item" is then graph-1 and graph-2. Google Structure Data Testing Tool validates graph-1 (the schema.org declarations) and then "acknowledges" the structure of graph-2.

[danbri]

@jaygray0919 interesting approach and much as we've hoped we'd see. Do you have a writeup somewhere?

[jaygray0919]

will be back to you with an illustration

[rvguha]

I tend to agree with Vicki and Dan. I would really like to avoid going down the path of making Thing the domain and range of too many properties.

[ostephens]

+1 to @danbri approach. But does this mean that partOfOrder needs to be moved out from under isPartof?

[chaals]

+1 to danbri's approach

[danbri]

Sounds like rough agreement. And thanks @acka47 - "For the sake of consistency, I suggest to stop listing partOfSystem and partOfOrder as subproperties of isPartOf as they also don't apply to creative works." - I agree that seems something we should fix.

[danbri]

Ok, I've gone ahead and made that change and pushed it to the staging site at http://webschemas.org/isPartOf

[webmaven]

@jaygray0919:

Currently, we use relevant schema.org terms in one graph, and then use a second graph for domain-specific ontologies such as Plant Ontology. So, with schema.org, we can declare the basics (name, Class, Thing), and then declare complementary, domain-specific, objects and relationships in a second graph. The "item" is then graph-1 and graph-2. Google Structure Data Testing Tool validates graph-1 (the schema.org declarations) and then "acknowledges" the structure of graph-2.

An example along those lines would be great. Which is the 2nd ontology you're using in this way?

[danbri]

Published via http://schema.org/docs/releases.html#v3.1
http://blog.schema.org/2016/08/schemaorg-update-hotels-datasets-health.html