Inverse properties

[MadsHolten]

I have seen examples where BOT is used to describe JSON-LD objects in a more traditional NoSQL database like Cosmos and in this case, the data is not queried with SPARQL (where you can easily query inverse properties with ^ or by reversing the triple pattern). In such an implementation it is useful to have the relationships directly available in both directions.

Therefore, I suggest that we implement the following inverse properties in BOT:

# Zone containment
bot:containedInZone a owl:ObjectProperty ;
    owl:inverseOf bot:containsZone .

bot:isBuildingOf a owl:ObjectProperty ;
    owl:inverseOf bot:hasBuilding .

bot:isStoreyOf a owl:ObjectProperty ;
    owl:inverseOf bot:hasStorey .

bot:isSpaceOf a owl:ObjectProperty ;
    owl:inverseOf bot:hasSpace .

# Element subcomposition
bot:isSubElementOf a owl:ObjectProperty ;
    owl:inverseOf bot:hasSubElement .

# Element/zone relationships
bot:isElementOf a owl:ObjectProperty ;
    owl:inverseOf bot:hasElement .

bot:elementContainedInZone a owl:ObjectProperty ;
    owl:inverseOf bot:containsElement .

bot:elementAdjacentToZone a owl:ObjectProperty ;
    owl:inverseOf bot:adjacentElement .

bot:elementIntersectingWithZone a owl:ObjectProperty ;
    owl:inverseOf bot:intersectingElement .

# Interfaces
bot:hasInterface a owl:ObjectProperty ;
    owl:inverseOf bot:interfaceOf .

Pros:

• More natural queries
• Richer data model
• More inferenced information
• Better performance in traditional noSQL stores (I think)

Cons:

• BOT is supposed to be minimal and with this change, it grows significantly
• Steeper learning curve for newcomers (we should consider not to have separate sections in the doc but only mention them as the inverse of the primary property)

Please comment if you have suggestions for better naming and if you agree/disagree with the need for such inverse properties.

[maximelefrancois86]

Hi,

Even if we don't add the inverse properties in BOT , you can still use keys in JSON-LD for them.

Reverse properties in JSON-LD 1.1 (was already part of JSON-LD 1.0) is exactly what you would be looking for:

See https://www.w3.org/TR/json-ld11/#reverse-properties

[mathib]

During LDAC2020, I noticed that Jan Voskuil marked inverse properties as "anti-patterns" and referred to the (implicit) way PROV-O deals with inverse properties. While I think it might be a bold statement to say it's an anti-pattern, I do believe there should be a good reason for adding them to BOT. If we do go ahead adding inverse properties, I think it's best to keep them separate (e.g. as an extension of BOT). In that way, the HTML documentation will not be overflooded with definitions and it will be clear what is the preferred (= the current) modeling?

[maximelefrancois86]

I think that beyond this issue, I understand that we should start to think about working on a JSON-LD context for BOT, and examples of how to use BOT in JSON-LD documents.

I think it would be a more valuable addition to BOT than further modifications to the schema itself

[GeorgFerdinandSchneider]

As of W3C LBD CG call on 30 June 2020 the discussion related to a JSON LD context is separated into a own issue #85

No decision is yet found on inverse properties. Opinions will be collected and the discussion is sent through the mailing list.

C0mments from call on 30 June:

[Mads] Issue raised in LDAC 2020 inverse properties should be helpful [Maxime] JSON LD context would be helpful [Maxime] Inverse properties allow several paths in queries, hence, a reasoner needs to be active in a triple store to avoid complex queries if not all property paths are materialised before [Mads] JSON (LD) support discussion should be separated [Joel] It should be easier to write GraphQL queries with inverse properties, makes things a little easier [Georg] Proposal: Could be good to have an extension with the inverse properties defined in a separate ontology [Pouya] Similar experience from using Neo4j, where inverse properties have been added [Georg] -> ACTION: Send discussion through mailing list