Back to transitivity...

[Simeon Warner]

I was involved in a couple of side discussions of the transitivity issue during the IIIF shimathon in Philly this week. The one issue that strikes me most forcefully is that, whatever the information modeling arguments for or against transitivity of some predicates, there is a very strong engineering argument against transitivity. Namely, if you have transitivity then all implementations of PCDM will be required to implement inference, and it seems unlikely to me that this is going to help PCDM meet the stated goal of being a "flexible, extensible domain model that is intended to underlie a wide array of repository and DAMS applications" [1]. 

Cheers,

Simeon

[1] https://github.com/duraspace/pcdm/wiki

[Esmé Cowles]

+1 -- we definitely don't want to require inferencing to implement PCDM.

But it might be a good extension -- if people do implement transitivity, it would be good for everyone to do it the same way.

-Esme

> --
> You received this message because you are subscribed to the Google Groups "PCDM" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pcdm+uns...@googlegroups.com.
> To post to this group, send email to pc...@googlegroups.com.
> Visit this group at http://groups.google.com/group/pcdm.
> For more options, visit https://groups.google.com/d/optout.

[Nick Ruest]

"it would be good for everyone to do it the same way."

+1 for an extension.

-nruest

[Daniel Lamb]

+1 for not complicating a basic use because of edge. It’s an edge that will eventually surface, but isn’t worth inconveinencing everyone all the time when many will have no need for it. A standardized extension is the fairest way to handle this for implementors.

~Danny

[Tom Johnson]

I'm increasingly convinced that this is a wait-and-see situation. The discussion on the GitHub issue[0] seems to have led to the conclusion that pcdm:hasMember should not be explicitly either transitive or intransitive. There's some guidance we should provide about the counter-intuitive upward inheritance of transitivity (if a sub-property is transitive; the super-property is also transitive by logical necessity[1]). 

Apart from that, it seems okay to let domain-specific PCDM implementations handle transitivity as required by their use cases. At least, if we pursue an extension with the idea of unified applicability, some more robust requirements gathering seems in order.

- Tom

[0] https://github.com/duraspace/pcdm/issues/29

[1] http://www.w3.org/TR/skos-primer/#sectransitivebroader (see the Note at the bottom of the section)

[Tom Johnson]

Copying this over from the previous thread so it doesn't get dropped. I've removed the various tech/dev lists; hope that's okay.

On Mon, Sep 28, 2015 at 3:33 PM, Diego Pino <dpino...@gmail.com> wrote:

Hi, just to resume and in the willingness to come to a resolution of this:

This is my reasoning about this (with also inline questions)

From the beginning:

pcdm:Object and pcdm:Collection are subclasses of ore:Aggregation, so we inherit their nature.

ore:Aggregation instances in ORE have a very special nature i don't see explicit present here: -> they define "split graphs" (means they define local graphs named Aggregation graphs), all having at least one ore:resourceMap (do we have resource maps? is the F4 serialisation an equivalent? how does the unique/distinct URI restraint conflicts with this?)

There was some discussion about the ore:resourceMap issue in a GitHub issue here: https://github.com/duraspace/pcdm/issues/16

You may want to jump in on that discussion if that doesn't seem adequately resolved.

 

 

IF pcdm:hasMember is a sub property of ore:aggregates, refined to only allow ore:Aggregation to ore:Aggregation relations (question also, why are we extending ORE by putting a pcdm property at that domain - range instead of at pcdm:object or pcdm:collection subclasses?) ,

I believe ore:Aggregation is being treated as a stand-in for `pcdm:Member U pcdm:Collection`; it seems nice to leave this loosely defined since it's more flexible for extensions. 

 

then as consequence it can not be transitive, because it connects two different graphs with (hopefully) at least two different ore:resourceMap instances -> meanings, etc.

This example illustrates clearly this notion http://www.openarchives.org/ore/1.0/datamodel#ore:isDescribedBy

I'm not sure I follow the conflict, here. Can you make this more explicit?

In either case, it doesn't seem like the issue would arise in the currently-under-consideration idea of pcdm:hasMemberTransitive as a super-property of pcdm:hasMember. In the worst case, you would need to do:

   pcdm:hasMemberTransitive a rdf:Property .

   pcdm:hasMember rdfs:subPropertyOf pcdm:hasMember Transitive .

   pcdm:hasMember rdfs:subPropertyOf ore:aggregates .

Omitting any claim that transitive membership is an aggregation relation. Yes?

Still, it would be nice to unpack this further.

 

So, in conclusion the very notion of subclassing ORE restricts the existence of transitivity, also because any assertion made about an entity is global (the reason we have Proxys, not only for ordering). If transivitiy where even an option, then everything that describes the first object in a chain would end "overwriting" the next ones and that is not the intention of ORE.

We can't assert the nature of an ore:aggregation, so any other predicates that should allow of inferring a transitive nature of chained objects using the same predicate should be tied to something not derived from ORE:

E.g , So if a pcdm:object could be also of rdf:type pcdmbook (if such thing would exist), then at this knowledge domain (separate Ontology) we can add whatever extra predicate we wan't to allow other inferences.but pcdmbook should in that case not be derived from ORE.

Finally, it all resumes to the actual implementation, without a reasoner and ontology enforcements (we don't have it, nor need it to make this interoperable) you can define you own logic to get whatever you wan't, traverse until fixed levels, if you need it fancy make your own OWL2 property chains or just get one graph defined by the resourceMap.

Cheers

-Diego

- Tom

[Diego Pino]

Hi Tom, thanks for copying this here:

I don't wanted to make this a complex theoretical statement about transitivity, but ORE makes a statement against transitivity by having separate ore:resourceMaps (what ever our implementation for this is) for each ore:Aggregation and as conclusion separate graphs. Graphs in this sense are a way of making clear semantic differences between groups of resources, So if you get to a point where you want to deep nest ore:Aggregations (or the pcdm flavour for those), then it's not completely correct to assume that we can use an ore derived predicate to make transitivity work. Because transitivity means we could end making false inferences in a real world repo, like that the first resourceMap applies to every children (you can put this into Protege). But this is theory, so:

I insist in the practical implications. Why would anyone need a transitive predicate explicitly declared here in PCDM without an inference engine. It's not needed to traverse the graph. It's not needed to define a structure of resources, moreover it adds a complexity to PCDM, because you could end having a graph of graphs (because that is chained group of ore:Aggregations in my understanding) connected with mixed predicates. So you would end having to traverse this using property paths in sparql (pcdm:hasMemberTransitive | pcdm:hasMember) * which leads to even further complexities in the case you really, really need inference and put a semantic engine somewhere.

Since ore allows rdf:type for other uses, then if a particular knowledge domain needs transitivity then those specific predicates can be put to work outside pcdm: as well as all other type of relations that don't imply a physical/structure parentship like the ones we try to describe in pcdm. The good thing about this approach is that even when your own system does not understand the rdf:type semantics it will still be able to understand pcdm.

I hope i explained this well and not added more to the confusion.

Best

-Diego

[Tom Johnson]

>  like that the first resourceMap applies to every children

This is where I think I lose you. I can't see where ORE claims that an Aggregations that aggregate other Aggregations share resource maps with their children. If this is the case, that is concerning indeed.

> I insist in the practical implications. Why would anyone need a transitive predicate explicitly declared here in PCDM without an inference engine. It's not needed to traverse the graph. ...

Here we are on the same page. I'm hopeful that we are close to resolving that transitivity is a non-issue, per the discussion on the GitHub issue.

I do think we need to agree on the implications of the point you raise above, before we can close the issue. Maybe Simeon can help?

- Tom

[Diego Pino]

Tom, you are right.I will put this the other way: in ORE there is no resource map sharing, thats one of reason we should not have transitivity here. 

1-  Every Aggregation has it's own, 

2.- Every aggregation is different and can be seen as a packaged group of resources

3.- We don't give them a semantic meaning outside of ORE to our objects in PCDM. For that we have rdf:type and there we are free.

ORE was made (please correct me, i could be wrong) to define packages(little local graphs again) of structured resources that can be connected in a sense of order, nothing more, nothing less.

And since resourcemaps:

 

1.- Describe an instance of an Aggregation 

2.- And are also graph , what you get when you relate something to a graph is that you belong to that one.

Think this as traversing "transitively" from the most far branch (tree of multiple nested) aggregation to the root one using hasMember. When you do this in your mind you never pass through the resource map, you follow a chain of identical predicates, but at the end of this graph traversal you get to a point where you can't go further with the same predicate, but you can get a resourceMap in one step. If transitivity where an option, an inference system would do this (they do, not all reason the same way) and conclude , that since n-depth aggregations tree is transitively connected to the root one and, from root one, he can reach a resource map, then that chain shares this map. Which is wrong!

But to avoid more confusions, i will stick to the practical implication: we don't need transitivity and also a ++ to close this issue.

Best, and thanks for trying to understand me, sometimes its even difficult for me.

-Diego

[Diego Pino]

Tom, sorry, i just re-read my very excessively complicated explanation on graph traversal and i think i put in the mix an even more complicated topic, inverse relations when having transitivity..(traversing back), so went sadly out of scope. Only that, i really don't wan't to add complexity to the discussion, goal that i'm clearly not reaching. I will try to stay as practical as possible.

Best

[Olli Lyytinen]

Hi everyone,

Let me just start by saying that I think codifying transitivity into pcdm:hasMember is probably a bad idea for a number of reasons and I'd rather do transitivity in some other way in those cases where it's needed.

But as I've been following this discussion, I've tried to to understand the finer details of ORE and I don't quite follow how the resource maps in ORE in themselves prohibit transitivity. It's very likely that I've not quite understood something and my goal here is to try to understand ORE rather than argue for transitivity in hasMember. So take all this as just academic curiosity.

This is they way I'm thinking about this. ORE has clear restriction about which resources can be linked with ore:aggregates inside a resource map. But this doesn't seem to be a problem because transitivity would never apply in a legal resource map. There can't be a chain of ore:aggregates relations in one. If there is, then that's not a valid ORE resource map in the first place.

Transitivity would only be relevant when you start combining multiple resource maps. And this is where things start to get vague, at least to me. As I understand it, this resource map concept is specific to ORE, it's not an RDF concept or an OWL concept. There's no specification on what happens or what should be done when you combine RDF statements from multiple ORE resource maps. I think when you get to the point where transitivity would apply, all bets are already off. At this point you already have chains of ore:aggregates relations, even without transitivity, which isn't allowed in an ORE resource map. But then again, at this point we're not operating in a single ORE resource map so this is not a problem. Similarly the implications of transitivity wouldn't be a problem. Does this make sense?

Thanks

Olli

[Robert Sanderson]

Hi all,

Simeon may wish to provide his recollections as well, as it has been almost a decade since we worked on ORE, but as far as I remember:

* ResourceMaps are a specific stance on the HTTP Range 14 issue.  Perhaps even stronger than the typical academic stance for 303s in favor of 200, in that the abstract Aggregation must explicitly refer to its serialization which also self-describes as a ResourceMap with various properties.

* The preclusion of multiple aggregations in a single ResourceMap follows from this stance -- if every Aggregation must have its own ResourceMap, then it makes no sense to have multiple in one.

* I don't believe transitivity was ever explicitly discussed, and any appearance to the contrary is likely due to our ignorance as newbie ontologists rather than anything intentional.

* Most use of ORE has ignored the ResourceMap requirement (see Europeana and DPLA, for example) and PCDM continues in that tradition by using the ontology rather than the more restrictive framework or protocol requirements that are layered on top of it.

So ... I would recommend simply not worrying about it :)  I agree with everyone else saying that we should remain explicitly silent about transitivity.  If an application wants to assume transitivity in its own domain, no one is going to complain. Nor if a different application assumes intransitivity.  

It seems to also be a much weaker form of transitivity that we're talking about, which is more hierarchical than ontological.  To compare:

    x owl:sameAs y ; y owl:sameAs z --> x owl:sameAs z  

holds for all of the semantics for owl:sameAs.

On the other hand, I don't think anyone wants to claim the same for transitivity of hasMember for all descendants of a Collection or Object?  It's not that 

    x hasMember y ; y hasMember z --> x hasMember z, 

and hence all descendants should be treated as children ... it's that they're descendants in a tree.  The inference would be:

    x hasMember y ; y hasMember z --> x hasChildOrDescendant z

Or have I missed something?

Rob

Rob Sanderson

Information Standards Advocate

Digital Library Systems and Services

Stanford, CA 94305

[Mike Giarlo]

Hi,

I thought it worth surfacing that this discussion is happening in two places. Here's the other place:

https://github.com/duraspace/pcdm/issues/29

(Not trying to steer; rather, to raise awareness.)

-Mike