Clarify transitivity of predicates

[azaroth42]

In mapping between PCDM and the DPLA MAP, a question arose as to whether hasMember is transitive. For example, given:

_:a pcdm:hasMember _:b .
_:b pcdm:hasMember _:c .

It should be stated that it is not true that _:a pcdm:hasMember _:c It may be valuable to have a pcdm:hasChildOrDescendantMember (or similar) predicate, but to be actually useful, it would need to be auto-created by the repository. Otherwise we would have the etag resource vs representation state problem to the nth degree.

[jpstroop]

I agree that pcdm:hasMember should not be transitive.

Just to confirm ore:aggregates and therefore dcterms:hasPart aren't transitive, right? I can't immediately find anything that says they are, but others may know more. It would be nice if dcterms said something explicit, because I have a feeling that transitive inheritance was their intent.

I also agree that there should be another predicate that is explicitly transitive. Use cases:

• PCDM for archives (series, subseries, files, ... )
• PCDM for Serials (Serial, Volume, Issue, Article ... )

[awoods]

The action out of discussions on this topic at HydraConnect3 is:

ACTIONS: sketch and propose on appropriate list. Don't introduce until someone expresses a real need.

See: Transitivity of Membership

[scossu]

@jpstroop: :+1: to non-transitive pcdm:hasMember :+1: to an explicit transitive membership predicate Does someone have a wide-spread use case of ore:aggregates or dcterm:hasPart as transitive predicates? I lean toward a name that does not resemble pcdm:hasMember and is not a refinement of it, since the use looks different to me. I think this is a fine line, though.

[DiegoPino]

:+1: to non-transitive pcdm:hasMember but i'm not sure if having, at base pcdm level an explicit transitive membership/parentship predicate is needed (useful). I fully understand the need to describe other deep graph use cases, but could that be handled on specific sub-ontologies (derived from pcdm), where finer granularly of more precise, domain specific, predicates could be used? So, isParentOf is a perfect sense -possible- transitive predicate (asymmetric also), but being so general, could this really assert the nature of a series, sub series, files tree structure more than the implicit assertion we get from traversing the graph down using other predicates? Just a thought.

[no-reply]

:+1: to non-transitive membership.

After taking a look at SKOS's handling of this, I think what we really want is for pcdm:hasMember to be agnostic about transitivity. It should not be explicitly intransitive, so that it may be used to express both transitive and intransitive relationships; but neither may be inferred based on the pcdm:hasMember relation alone.

As for the need for an explicitly transitive membership property, I think we need this if we care about the interoperability of using inference to support Jon's use cases (and I'm sure many others). This predicate should have a clear relationship with pcdm:hasMember, so we can avoid the need to assert both predicates. I would suggest pcdm:hasMemberTransitive as a superproperty of pcdm:hasMember (the subproperty relation would have the wrong result, as described here).

[...] a property P is a sub-property of Q if and only if every time P holds between two resources, then Q also holds between them. This does not enforce any transitiveness inheritance: on the contrary, the set of all couples of resources related by P (its graph), as a subset of Q's, is likely to miss some of the couples that make Q transitive.

@jpstroop said:

It would be nice if dcterms said something explicit, because I have a feeling that transitive inheritance was their intent.

Most of the KOS literature I can find explicitly declares partitive relations to be not necessarily transitive. The following, for example, seems natural but we normally wouldn't want to infer the transitive relation:

:conductorsArm dct:isPartOf :conductor .
:conductor dct:isPartOf :orchestra .

I suspect DC simply takes this for granted.

[escowles]

:+1: to non-transitive membership. I think there are clearly cases where membership is transitive, but I haven't seen an interoperability use case for it. If we find a use case for it, then adding a new transitive property probably makes the most sense.

AFAICT, there is no owl:IntransitiveProperty or equivalent to explicitly record this. Maybe we should add a sentence to the wiki and/or the hasMember description?

[jpstroop]

I'm now thinking that we should be explicitly silent about transitivity--I agree w/ Esmé that there's not a clear use case related to interoperability (at least yet). Maybe it's better to let implementations in different domains decide whether or not membership is transitive.

[atz]

When A, B, and C are the same type, at least specifically when they are Collections, it seems entirely worthless to reason about them as though A hasMember C is false or schmaybe. That is the point of the relationship. It may be insurmountably difficult to make that ontologically clear, but that is certainly the intent of the design, as I've understood it.

[mjgiarlo]

schmaybe++

[jpstroop]

@atz Are you suggesting that Collections be transitive via hasMember and Objects not? Just trying to make sure that I understand your point (difficulties/practicalities aside).

[escowles]

@atz @jpstroop That is the way UCSD at least has understood a collection hierarchy. Given:

col1 hasMember col2
col2 hasMember col3
col3 hasMember obj1

We would index obj1 as belonging to col1, for purposes of counting/listing/etc. the objects in col1

[jpstroop]

I can see that w/ Objects too, though: Scene 1 is part of Act I is part of the the Opera, so maybe where we were?

[DiegoPino]

@escowles, i don't think you need implicit transitivity for that, a sparql query with a statement like this (just an incomplete example part of a full one) is enough to get everything in any collection

<anycollectionuri> pcdm:hasMember+ ?object

using property paths, and then you filter by ?object results that are only instances of pcdm:object excluding collections(if needed) and/or add an additional statement about what rdf:type should ?object have.

[acoburn]

:+1: to non-transitive membership for both objects and collections.

@DiegoPino++ for the suggestion to use Sparql transitive queries for nested collection membership.

[tpendragon]

@DiegoPino @acoburn To clarify, that argument is that transitivity is business logic and not a modeling concern?

[acoburn]

@terrellt yes, application-specific business logic.

[jpstroop]

That's what I'm hearing, which is different from explicitly saying that hasMember is non-transitive.

[escowles]

:+1: to the ontology being silent on transitivity, and having applications sort out any transitive relationships they need.

[tpendragon]

I'm taking @no-reply's stance here:

As for the need for an explicitly transitive membership property, I think we need this if we care about the interoperability of using inference to support Jon's use cases (and I'm sure many others).

It appears hasMember should be explicitly non-opinionative. If we can close this issue on those grounds, then great. However, I'm :-1: on placing the responsibility of enacting inference on business logic - transitivity seems like an important piece of structural metadata (I don't think a usable version of our metadata should be RDF + ruby). If we have to solve that outside the scope of PCDM, then very well, but I expect this will come up again, and a superproperty within PCDM seems like it would be a community win.

[azaroth42]

:+1: to closing, won't-fix. I agree (also as per list) that transitivity of membership can be more easily dealt with at the business/application logic level, rather than the ontology. If we absolutely must pick something, it should be that the ontology is intransitive, but that applications may wish to treat it as transitive in certain situations and may do so in the privacy of their own implementations.

[jpstroop]

If we absolutely must pick something, it should be that the ontology is intransitive, but that applications may wish to treat it as transitive in certain situations and may do so in the privacy of their own implementations.

Should something along those lines be in the ontology's rdfs:comment about hasMember?

[jpstroop]

It seems to me like being explicitly silent, as opposed to just saying nothing would be a good idea.

[escowles]

Yes, this is probably a good idea to be explicitly silent. How about "Note on transitivity: hasMember is not defined as transitive, but applications may treat it as transitive as local needs dictate."

[mjgiarlo]

:+1:

[jpstroop]

If it's not defined as transitive, is it defined as intransitive? Maybe, "This ontology makes no recommendation regarding the transitivity of hasMember. Applications may may treat it as transitive or intransitive as local needs dictate."

Or do we want to express a slight leaning toward intransitive, as @escowles recommendation does (at least to me)?

[mjgiarlo]

Creating a linkage between this discussion and the one on the PDCM group: https://groups.google.com/d/msg/pcdm/_Nw42hq71xQ/VajhHlniBQAJ

[jpstroop]

Thanks @mjgiarlo !

[mjgiarlo]

You bet, @jpstroop! Carry on, sir.

[DiegoPino]

:+1: to non-transitive membership for both objects and collections. Means close-won't fix :+1: as @azaroth42 stated. :smile:

Maybe we should just relay on owl syntax for this instead of explaining further, the whole reason for having an ontology is to use it, so if we don't define it as owl:TransitiveProperty then every one can assume how to fetch individual or chained relations by "business logic" i they need to. There is no explicit "intransitiveProperty" for a good reason. I think it also makes sense if PCDM grows in the future, so we don't have to explain in comments every property that is not defined as owl:TransitiveProperty.

About @terrellt concern

However, I'm :-1: on placing the responsibility of enacting inference on business logic - transitivity seems like an important piece of structural metadata (I don't think a usable version of our metadata should be RDF + ruby).

I understand the use cases and even a possible need in the future but all of them are very domain specific. Even using a reasoner is in someway business logic, and i don't see currently a use case that can't be resolved without reasoners nor how this limits the usability, not having transitive properties gives us so much more flexibility. Even implementing PCDM over LDP requires "business logic", so why not fetching?

But there is also a a inherited condition of PCDM that speaks against using transitivity. We are not modelling a part-of-whole ontology.

Part of a whole ontologies are very domain aware and in those knowledge domains you can really "inference", but having a pcdm:object class is almost as having a "isaStructuredThing" class that subclasses some of the ore restrictions and pcdm:Collection is a collection of hopefully flexible things. If you put transitivity in place you end restricting the possible meanings of what an object should be. I don't want to give this more thoughts, but here is a good/ nice reference (look at the "Relations that are not simple part-whole relations in the sense above")

http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/

If you look a this somehow old, but very valid document, membership and containment are not part-of-a-whole cases.

[tpendragon]

Even using a reasoner is in someway business logic, and i don't see currently a use case that can't be resolved without reasoners nor how this limits the usability...

It doesn't limit usability at all, what I'd be concerned about is interoperability. That being said, it seems like the consensus is that transitivity is an implementation concern and the reasoning done on that implementation should be assumed to not be interoperable with other systems implementing PCDM.

In short, I yield. =) Thanks for the discussion.

[kestlund]

I think this discussion illustrates that we cannot simply let the ontology do the work for us. We need the results of this discussion to appear somewhere other than a closed issue in order to avoid repeating it and to act as a guide. After we agree on that, then I think we should close this issue with a close won't-fix.

:+1: to @escowles "Note on transitivity: hasMember is not defined as transitive, but applications may treat it as transitive as local needs dictate." using this toward intransitive language but not being entirely explicit.

Although I agree with @DiegoPino in principle about adding it to the ontology creates additional baggage, I'm not sure it means we have to do the same for all our other properties. I think our goal should be ease of use (and since it doesn't break any semantic rules) and not symmetry. If other future properties prompt the same confusion/question, then we might want to have the same comment. On the other hand, if we don't put the comment in hasMember, are there other recommendations on where to put the comment to be easily found by people using the ontology?

Re: defining transitivity: Going back to the Google thread, the discussion on 2015-10-02 to wait on some of our implementations and then look at possible optional extensions to address the problems as raised by @terrellt and @no-reply (and others) still seems to me to be valid. I do not think that this will be the last of possible extensions that are raised for PCDM.

[ruebot]

@kestlund would it be worth adding a section to the wiki about this issue?

[kestlund]

@ruebot the wiki was my first instinct, but here's my question, "would you look there for this kind of information?" If the answer, is yes, then let's put it there. If no, then I think we should think more seriously about just adding the comment in the ontology right where people are looking.

[ruebot]

@kestlund I think it would be good in both places. We can use the wiki if we want to be more verbose about it. Or just link back here?

[daniel-dgi]

@ruebot @kestlund Different folks from different walks of life will look in different places. I'd take a carpet bomb approach and put it everywhere you think someone would read it. Personally, I'd probably wind up on the wiki first before jumping into the ontology. But that's just me.

[jpstroop]

(:car: + :hamster:) :bomb: :+1:

(car-pet bomb +1)

[mjgiarlo]

(:car: + :hamster:) :bomb: :+1: (car-pet bomb +1)

Is that scheme or lisp? It looks like my emacs config.

[no-reply]

:+1: to explicit schmaybe transitivity. :+1: to documenting this fact in several well chosen places. We should also encourage folks using transitivity to document their implementations in those places.

@DiegoPino said:

Maybe we should just relay on owl syntax for this instead of explaining further, the whole reason for having an ontology is to use it...

:-1: to use of OWL in PCDM. OWL sits at a higher level, and with a much higher bar to support, than RDF and RDFS. Introducing OWL semantics is an expense I'm concerned our applications (and architectures) can't afford.

@terrellt said:

, I'm :-1: on placing the responsibility of enacting inference on business logic - transitivity seems like an important piece of structural metadata (I don't think a usable version of our metadata should be RDF + ruby).

I agree with the first and the last (parenthetical) part of this. I think the middle transitivity seems like an important piece of structural metadata part, only holds if we care about interoperability of transitivity. It seems like the decision we are coming to is that PCDM doesn't care about that.

I don't think this is the same as saying it's a business logic concern. It's still a modelling concern, and it's important that we treat it as such. It's just not PCDM's modelling concern.

So :-1: to saying "just implement in SPARQL"; but :+1: to saying "you can implement using SPARQL". :)

@mjgiarlo said:

Is that scheme or lisp? It looks like my emacs config.

One can only assume it's emojilisp.

[mjgiarlo]

One can only assume it's emojilisp.

[kestlund]

...so in trying to close this...

Can we agree to the following? 1) Put in the rdfs:comment for hasMember "Note on transitivity: hasMember is not defined as transitive, but applications may treat it as transitive as local needs dictate." as per @escowles and @jpstroop

2) Write a nice little summary in the wiki that points to this, which will then be closed, issue.

[ruebot]

@kestlund :+1:

[no-reply]

:+1:

[daniel-dgi]

:+1: