Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does a subproperty imply a property? #1896

Closed
chharvey opened this issue Apr 24, 2018 · 7 comments

Comments

Projects
None yet
2 participants
@chharvey
Copy link

commented Apr 24, 2018

If a is a subproperty of b, then does <X> <a> <Y> imply that <X> <b> <Y>?

Example: <Alice> <loves> <Bob> implies <Alice> <knows> <Bob>, since a person must know someone in order to love them.

If I understand this correctly, then I would think that the domain and range of <loves> should be subclasses of the domain and range, respectively, of <knows>.

Let’s assume that <knows> has a domain and range of <LivingCreature> (i.e., <LivingCreature> has a <knows> property, which must have value(s) of type <LivingCreature>).

'knows': {
  domain: ['LivingCreature'],
  range: ['LivingCreature'],
}
// example:
<my-dog> <knows> <me>

And <loves> has a domain of <Human> and a range of <LivingCreature> (since we do not yet know if animals or machines can love, and, debatably, a human can love only living creatures).

'loves': {
  domain: ['Human'],
  range: ['LivingCreature'],
}
// example:
<me> <loves> <my-dog> // (therefore `<me> <knows> <my-dog>`)

Then it is safe to assume that:

<loves.domain> <rdfs:subClassOf> <knows.domain>
<loves.range> <rdfs:subClassOf> <knows.range>

If this were not the case, then it would be possible that <X> <loves> <Y> where <X> could be a non-human and/or <Y> could be a non-living creature. Conversely, it would also be possible that <X> <loves> <Y> but not that <X> <knows> <Y>. (A concrete example is shown below.)


Here’s a live example: (where "sdo": "http://schema.org/")

{
  "sdo:identifier": {
    "rdf:type": "rdf:Property",
    "rdfs:domain": ["sdo:Thing"],
    "rdfs:range": ["sdo:Text", "sdo:URL", "sdo:PropertyValue"]
  },
  "sdo:sku": {
    "rdf:type": "rdf:Property",
    "rdfs:subPropertyOf": "sdo:identifier",
    "rdfs:domain": ["sdo:Demand", "sdo:Offer", "sdo:Product"], /* all subclasses of Thing */
    "rdfs:range": ["sdo:Text"] /* a restriction on the union of Text||URL||PropertyValue */
  }
}

We can see that the domain of <sdo:sku> is a subclass of, or at least a restriction on, the domain of <sdo:identifier>, and the same is true about their ranges.


If this all makes sense, then shouldn’t there be efforts made that domains and ranges of subproperties are each subclasses of the domains and ranges, respectively, of the properties they extend? I see a lot of cases where this principle is not upheld, including:

{
  "sdo:location": {
    "rdf:type": "rdf:Property",
    "rdfs:domain": ["sdo:Action", "sdo:Event", "sdo:Organization"],
    "rdfs:range": ["sdo:Place", "sdo:PostalAddress", "sdo:Text"]
  },
  "sdo:homeLocation": {
    "rdf:type": "rdf:Property",
    "rdfs:subPropertyOf": "sdo:homeLocation",
    "rdfs:domain": ["sdo:Person"] /* not a subclass/restriction on Action||Event||Organization */
    "rdfs:range": ["sdo:ContactPoint", "sdo:Place"] /* ContactPoint is not a subclass of PostalAddress */
  },
  "sdo:foodEvent": {
    "rdf:type": "rdf:Property",
    "rdfs:subPropertyOf": "sdo:homeLocation",
    "rdfs:domain": ["sdo:CookAction"] /* valid, as a subclass of Action */
    "rdfs:range": ["sdo:FoodEvent"] /* not a subclass/restriction on Place||PostalAddress||Text */
  }
}

Because of these discrepancies, we can have a situation in which, e.g., <Alice> <homeLocation> <some-contact-point> is valid, but <Alice> <location> <some-contact-point> is not. Since we cannot be guaranteed that <homeLocation> implies <location>, it would not make sense that <homeLocation> is a subproperty of <location>.

@RichardWallis

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2018

If I understand you correctly, you are suggesting that In terms of the Schema.org website interface the expected type(s) listed for a property should include those of the property's super-properties.

In data terms, that would mean that the effective rangeIncludes for a property would be the sum of the contents of its rangeIncludes plus the rangeIncludes of the property that it is subProperty of.

If that is correct, I have some sympathy for that view.

@chharvey

This comment has been minimized.

Copy link
Author

commented Apr 24, 2018

@RichardWallis not exactly. I’m suggesting that a sub-property’s rangeIncludes (“expected type”) should be a restriction on that of its super-property, the property that it “extends”. The same should be said about a sub-property’s domainIncludes (“used on these types”).

In my second example, where sku extends identifier, the domainIncludes of sku is Demand||Offer||Product, and the rangeIncludes is Text. These are restrictions of the domainIncludes and rangeIncludes of its super-property identifier—which are Thing and Text||URL||PropertyValue, respectively.

If I am to be precise, not all restrictions are subClasses. If a property’s domain is a union such as Action || Event || Organization, then all of its sub-properties should have a domain that is restricted by that union. It could be just one or two of those classes, or all three, or it could be a subclass of any of them, or any union of such subclasses. Similarly, if a property’s domain is just one class Action, then all of its sub-properties should have a domain that is restricted by that class, such as Action itself, or a single subclass, or a union of subclasses of Action. The bottom line is that the entire domain of a sub-property should be contained within or equal to the entire domain of its super-property. The same exact thing should be said about ranges.

Only then will a sub-property be able to imply its super-property, i.e. if <X> <sub-property> <Y> is a valid statement then <X> <super-property> <Y> is also valid.

@RichardWallis

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2018

@chharvey I am a little confused about your rangeIncludes suggestions:

In my second example, where sku extends identifier, the domainIncludes of sku is Demand||Offer||Product, and the rangeIncludes is Text. These are restrictions of the domainIncludes and rangeIncludes of its super-property identifier—which are Thing and Text||URL||PropertyValue, respectively.

That is what happens now:
sku expected type: Text
identifier expected type: PropertyValue, Text, URL

With regard to domainIncludes, I think what you are saying is that a sub-property should only include in its domainIncludes types that are in its super-property's domain (and their subtypes).

I don't agree with that. The flexible approach to the development and structure of the vocabulary depends on the ability to use, and reuse, suitable properties in appropriate types. This as described in general terms on the Data Model page, including the reference to Postel's Law.

@chharvey

This comment has been minimized.

Copy link
Author

commented Apr 24, 2018

@RichardWallis Yes it sounds like you understand now the point I was making. My identifier/sku was an example that illustrates how I think the property-subproperty relationship should be modeled, not a complaint. My complaint is that not all properties and subproperties obey this model, as demonstrated at the end of my first comment (the location/homeLocation example).

If my interpretation that “a subproperty implies a property” is correct—that is, if <a> is a subproperty of <b>, then whenever <X> <a> <Y>, we can infer <X> <b> <Y>—then the model that I’m requesting, exemplified by identifier/sku, should prevail.

But again as I’ve pointed out, if you don’t want the domain/range of <b> to sit inside the domain/range of <a>, then we are able to make valid statements like <W> <b> <Z>, at the risk of <W> <a> <Z> being an invalid statement. We lose the power of inference, and more importantly, the definition of what it means for one property to “extend” or “imply” another property.

Per my example above: assume <Alice> is a <Person> and <Alice’s Home> is a <ContactPoint>. Then the statement <Alice> <homeLocation> <Alice’s Home> is valid, since <homeLocation> has a domain of <Person> and range that includes <ContactPoint>. (In simpler terms, the Person class has a homeLocation property that expects values of type ContactPoint.)

Now because <homeLocation> is a subproperty of <location>, we would like to infer that the statement <Alice> <location> <Alice’s Home> is also valid. As you can see, this is a problem because <location> does not allow a <Person> to be in the domain, nor does it allow <ContactPoint> to be in the range. (Person has no location property, and even if it did, location does not expect values of type ContactPoint.) So either the domain/range of homeLocation should be adjusted to fit inside the domain/range of location, or else homeLocation should not be marked as a sub-property of location.

My suggestion in general is to adhere to the “rule” that a sub-property’s domain/range should be subsets of its super-property’s domain/range. Otherwise, it should be redefined what it really means for a property to be a “sub-property” of another.

@RichardWallis

This comment has been minimized.

Copy link
Contributor

commented Apr 27, 2018

@chharvey Having looked closer at location and homeLocation I am a now a little less confused as to what you are highlighting.

i.e. homeLocation has ContactPoint as an expected type, whereas its super-property location does not have it as an expected type.

What I believe you are seeing here is symptomatic of the flexible, consensus driven, evolving nature of the vocabulary that is Schema.org, as against a strongly constrained, rules based ontology.

As mentioned on the Data Model page "The type/properties associations of schema.org are closer to "guidelines" than to formal rules"

So, to simply answer the question in the title of this issue "Does a subproperty imply a property?". No.

@chharvey

This comment has been minimized.

Copy link
Author

commented Apr 27, 2018

@RichardWallis Thank you for clarifying. I understand that the structure/relationship of Schema.org vocabulary terms is adaptive and lenient as opposed to a more rigorous ontology. It makes me wonder, then, what’s the point of having subproperties at all? If there’s no rigorous condition that “a subproperty implies a property”, then is there really a strong case for documenting one property as a subproperty of another, and how will this help authors in a meaningful way, without confusing/frustrating them?

@RichardWallis

This comment has been minimized.

Copy link
Contributor

commented Apr 27, 2018

It's all about guidelines. Indicating the type of relationship a property has with the Types included its domain. That type of relationship often being more specific for the sub-property.

So, loosely, a Thing (or one of its many subtypes) can have an identifier of many types. However, an isbn (a specific category of identifier) is only relevant as a property for one of those subtypes, Book.

Seeing how a super-property relates to the types in its domain can give examples/guidance as to how a subtype may be used.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.