The ontology should express inverseOf for its relationships

[azaroth42]

Issue:
The ontology currently does not express the inverse for the relationships it defines. For example, hasMember and memberOf are not declared as inverses.

Rationale: The presence of inverses in the data is useful for Linked Open Data representations to ensure that regardless of which resource you enter the dataset at, you can trace your way to all of the other related resources by simply following your nose, rather than requiring sparql queries against the entire dataset. The formal definition of the inverse allows these to be automatically computed rather than materialized in the database.

Proposal:
Add the following triples to the model:

pcdm:hasMember owl:inverseOf  pcdm:memberOf
pcdm:hasFile owl:inverseOf pcdm:fileOf
pcdm:hasRelatedObject owl:inverseOf pcdm:relatedObjectOf

[DiegoPino]

@azaroth42 ok. owl:inverseOf must be using inside <owl:ObjectProperty> so can not be used in <rdf:Property ...>. Please correct me if i'm wrong.

[acoburn]

If the PCDM ontology has an owl:imports <http://www.openarchives.org/ore/terms/> statement, then you get all of those inverse statements "for free".

[escowles]

@DiegoPino I think you could define the predicates as both rdf:Property and an owl:ObjectProperty, e.g.:

pcdm:hasMember a rdf:Property, owl:ObjectProperty ; 
    rdfs:label "has member" ;
    rdfs:domain ore:Aggregation ;
    rdfs:range ore:Aggregation ;
    rdfs:subPropertyOf ore:aggregates ;
    rdfs:isDefinedBy <http://pcdm.org/models#> ;
    owl:inverseOf pcdm:memberOf .

[azaroth42]

Open World lets us assert anything about anything. The implication is that the subject and object are instances of owl:ObjectProperty, but we don't need to materialize those assertions. Systems that care will know from inference on OWL. Systems that don't care or don't do inferencing, don't care.

[escowles]

@acoburn I don't think that's true — I think you'd know their super-properties were inverses, but you wouldn't know which PCDM properties were inverses of what.

[DiegoPino]

Open World lets us assert anything about anything.

o no. Open World means that if not explicitly stated it can be possible somewhere

[acoburn]

@escowles ah, you're correct, you'd only know that pcdm:hasMember is an inverse of ore:isAggregatedBy, which is different than knowing that it is an inverse of pcdm:memberOf.

[escowles]

I agree with @azaroth42 too — we wouldn't have to explicitly declare that our predicates were owl:ObjectProperties — it could be inferred from the domain and range of owl:inverseOf.

I don't have a strong preference either way.

[acoburn]

I also agree with @azaroth42: there is no need to materialize those triples, since the types can be inferred (if the client cares about such things).

[azaroth42]

@DiegoPino I'm not sure how that's helpful? My point stands that we CAN assert owl:inverseOf about something that we declare as an rdf:Property because if is possible for it to be declared somewhere as an owl:ObjectProperty. And indeed, the fact that the domain and range of owl:inverseOf are specified as owl:ObjectProperty means that it can trivially be inferred, even by a system that only does RDFS. Sorry if the shorthand for that was too short.

[DiegoPino]

@azaroth42 maybe i'm too rigid, sorry, i'm really trying to be helpful. But according to this http://www.w3.org/TR/owl-ref/#inverseOf-def domain and range of owl:inverseOf is owl:ObjectProperty. So i don't see how using rdf:Property in the mix can be done. When doing reasoning schemas come in place, not sure if a reasoner will understand such an cross-domain definition. Can someone provide an example Ontology that uses this idea somewhere else.

[azaroth42]

Domain and range do not restrict anything, they simply assert that any resource that is the subject or object (respectively) can be inferred to also have that class.

[acoburn]

@DiegoPino you'll see in the ORE ontology that ore:aggregates is defined like so:

  <rdf:Property rdf:about="http://www.openarchives.org/ore/terms/aggregates">
    <rdfs:label>Aggregates</rdfs:label>
    <rdfs:comment>Aggregations, by definition, aggregate resources. The ore:aggregates relationship expresses that the object resource is a member of the set of Aggregated Resources of the subject (the Aggregation). This relationship between the Aggregation and its Aggregated Resources is thus more specific than a simple part/whole relationship, as expressed by dcterms:hasPart for example.</rdfs:comment>
    <rdfs:subPropertyOf rdf:resource="http://purl.org/dc/terms/hasPart" />
    <rdfs:domain rdf:resource="http://www.openarchives.org/ore/terms/Aggregation" />
    <rdfs:range rdf:resource="http://www.openarchives.org/ore/terms/AggregatedResource" />
    <owl:inverseOf rdf:resource="http://www.openarchives.org/ore/terms/isAggregatedBy" />
    <rdfs:isDefinedBy rdf:resource="http://www.openarchives.org/ore/terms/"/>
  </rdf:Property>

[DiegoPino]

@acoburn scary! specs say different again. I'm so confused

[azaroth42]

I hope this quote from RDF Schema 1.1 helps:

The rdfs:range property can be applied to itself. The rdfs:range of rdfs:range is the class rdfs:Class. This states that any resource that is the value of an rdfs:range property is an instance of rdfs:Class. The rdfs:range property is applied to properties. This can be represented in RDF using the rdfs:domain property. The rdfs:domain of rdfs:range is the class rdf:Property. This states that any resource with an rdfs:range property is an instance of rdf:Property.

Therefore, given that:

owl:inverseOf rdfs:range owl:ObjectProperty

We can conclude that owl:inverseOf is an rdf:Property, and that owl:ObjectProperty is an rdfs:Class.

Thus it cannot be wrong to state:

pcdm:hasMember a rdf:Property ;
  rdfs:range ore:Aggregation ;
  owl:inverseOf pcdm:memberOf .

Convinced? :)

[no-reply]

Agreed with @azaroth42 that the owl:ObjectProperty statement can be elided and inferred. I don't believe rdf:Property and owl:ObjectProperty are disjoint. In OWL 1, it was a subproperty (i'm not sure of the OWL 2 status).

Note that this addition implies that no instances of pcdm:Collection, pcdm:Object, and pcdm:File are an owl:Class. I don't think this directly impacts RDFS users, in the absence of other changes.