Can we have pcdm:isMemberOf?

[ptsefton]

When ingesting data an object may know which collection it wants to belong to, would be good to be able to express the inverse of pdcm:hasMember (I don't know much about RDF, is this a silly request?)

[escowles]

I think this makes sense, and it would probably be good to include reciprocal properties of the other properties too:

pcdm:memberOf
pcdm:relatedObjectOf
pcdm:fileOf
pcdm:relatedFileOf

[ruthtillman]

I agree it makes sense. Was just encountering this in my PCDM modes. I think the beauty of RDF is that you ultimately don't have to, but practically-speaking it'd make a lot of sense to set up reciprocal properties.

[acoburn]

I disagree for two reasons.

1) One aim of the PCDM is to encourage consistent modeling practices across repositories. If the model includes both pcdm:hasMember and pcdm:isMemberOf, then you suddenly have three ways of modeling objects: using only pcdm:hasMember, using only pcdm:isMemberOf, and using both. This means that any client implementation (Hydra, Islandora, etc) would need additional code logic to handle three cases instead of one.

2) If you need access to these inverse relationships, a good external triplestore will already provide that information for you

That said, LDP does already have an ldp:isMemberOfRelation that could be used for this sort of thing. I just think it is important to weigh the benefits of such additional predicates against the additional complexity that will emerge in users' modeling practices.

[scossu]

I agree with @acoburn that it is more efficient and manageable to have one way of cataloging resources and their relationships and many ways to publish them, using external tools.

On the other side I can see the utility of relying on the inverse relationships and to have these formalized in an ontology without incurring in the extra maintenance that @acoburn mentioned.

Would it make sense to have a "core" ontology which a PCDM-compliant system must implement in full, and an "optional" subset that individual implementers decide internally to comply to?

[escowles]

I can see the reciprocal properties being an optional extension. From an implementation standpoint, it does seem like having a single pattern would make things easier. Using the LDP patterns, you would post the Object, and then create a proxy in the collection's members container. So I don't think the reciprocal predicates would help.

But if you were using a different platform, then I can imagine just creating the Object with the isMemberOf predicate.

[DiegoPino]

Hi, just a few thoughts on this. I don't fully agree with @acoburn on this (sorry). A formal ontology does not allow multiple ways of modelling things, if well formed, sufficiently restricted and correctly implemented/interpreted by our code. But on the other side, FF manages directed, acyclic graphs, so we could live without inverseof.

http://www.w3.org/TR/owl-ref/#inverseOf-def

It's true, that in a practical implementation, having inverse relations makes things a bit more complicated when defining relations initially and when moving and deleting resources around. Also adds a lot of extra triples to a triple store(bad), but also allows a much more cleaner graph traversal when fetching related resources, specially when navigating linked data. The additional code logic (already implemented this on FC3 + Islandora, and being this based on my experience dealing with formal ontologies) is more, true, but could have practical benefit/impact, also when validating statements. It makes triple store querying (Sparql) consistent and linked data navigation easier.

I don't fully understand how a good external triple store would provide that information, i suspect you mean reversing subject predicate object statements when querying?, but this also adds extra logic to coding. Or are we talking about an OWL reasoner/triple with reasoning capabilities? (even in that case someone must define somewhere an inverseof)

The problem or better said, what i personally see, is that, by having the current ontology defined on rdfs namespace and inferring rules(i mean classes and properties), we are handling basically a OWL FULL ontology. FULL means, reasoning is almost impossible. E.g, did you know that in rdfs a class definition can be also be used as an individual (object - thing) definition? And in that scenario, i must say @acoburn is right.

Also i must admit i'm going here a bit too strict on definitions, many existing ontologies are written in rdfs with some owl statements (but also many only in owl), but anyway inverseOf is in the owl world and in that world things should be more controlled.

By defining that a certain property is the inverse of another one, we are asserting that there is symmetry (or go further and add functional properties if needed). We can infer relationships. We can even enforce them. We can traverse back and forth in our graphs. We can even split different knowledge subgraphs. And on a practical implementation we can define them only on one of the properties, so coders can always choose one direction if they wan't when implementing.

But giving @acoburn credit again, it's difficult to maintain, store and to enforce.

@scossu is also right. You can extend and refine ontologies and add extra logic out of the core,e.g, just to be able to display labels on the UI side if you wan't, could be also an option of course.

If you look at http://www.openarchives.org/ore/terms/, inverse ones are defined.

As stated, just ideas, no harm intended nor trying to impose my owl mind here. There is so much discussion and different ideas on the subject googling around that it's almost impossible to state which works better. So keeping it simple is always a good choice.

[azaroth42]

My 2c: Having explicit inverse properties is valuable in a distributed environment, where the structure might be unknown in advance. The current implementation practices for PCDM have not gotten to thinking about that yet, as it's very new. In the ontology I see no problem in defining inverse relationships for people to use if needed. However in the documentation and implementations, we should recommend consistent patterns of use based on experience. In that scope, I think we would want to say to typically use hasMember not isMemberOf. The LDP projection is at the same level; it's a practical use of the model and ontology, but not one that's required to use the model.

[ruthtillman]

++ @azaroth42

[DiegoPino]

++ @azaroth42 , exactly our use case. We link multiple distributed repo's and having inverse of is fundamental. Thanks!

[acoburn]

I am completely supportive of the suggestion from @azaroth42 As an ontology, it makes perfect sense to have inverse relationships. My concern stemmed entirely from the desire to have consistent models of use from an implementation perspective. That could easily be handled with proper documentation.

[ptsefton]

The use case that sparked my question is that I'm designing a CSV importer, initially to work with Omeka which has a simple collection / item hierarchy with each row in the CSV representing an item (pcdm:Object). It's much more natural in that environment for the item to declare what collection it belongs in and I'd like to embrace PCDM so we can later ingest the same data into Fedora.

Another use case would be surfacing member relationships on an object page in a web site. Wouldn't you want an item page be able to say isMemberOf in RDFa embedded in the site?

If you're implementing PCDM outside of Fedora there are lots of cases where maintaining lists of members is not going to be a good implementation choice, you may not be using a triple store, are you concerned about those or is this a Fedora specific model?

[azaroth42]

@ptsefton Thanks for the background, and I think the use case of RDFA across pages is a really solid one. And to answer the question, the model (in my not so humble but I hope shared opinion) should definitely not be tied to Fedora, LDP or even an RDF specific processing stack. It would be great if a completely non-rdf-aware stack could consume an agreed upon JSON-LD representation and make as much use of it as a full on graph processor :)

[ptsefton]

Hi all, thinking a bit more about this I realise that in a use case like mine I don't really need the inverse relationship just a way of expressing the relationship the other way. Ie instead of the row in the CSV file representing a pcdm:Object being the subject it could be the object - so there would be two flavours of relational columns one for 'This item is subject of isMemberOf' and one for 'This item is object of hasMember'. Was thinking too much in terms of the traditional name:value metadata.

Will be hard to explain though, I dread writing the how-to.

Still, the inverse relationship would be handy.

@azaroth42 +1 to your comments re the model being stack-agnostic.