Stick with RDFS or switch to OWL

[escowles]

There is a proposal to switch from encoding the core ontology in RDFS and to use OWL instead because it is more expressive and can encode things like pcdm:hasMember and pcdm:memberOf being reciprocal properties.

Should we switch to encoding the core ontology in OWL?

See #53 for preliminary discussion.

[ruebot]

👍 OWL

EDITED

[whikloj]

I think that the goal from my perspective with PCDM is interoperability.

Because we are looking at multiple very different applications, I feel like the goal is less about RDFS vs OWL and is more about adding some description and (dare I say) restrictions to the ontology.

This would make it much easier for people implementing PCDM to follow the data model. Rather than checking an application's/group's/community's implementation documentation (which could change). But this is just my opinion.

[DiegoPino]

@whikloj true, but OWL 2 (also a matter of which profile we choose) has the necessary expressiveness to add restrictions and other semantic constructs +opening inference capabilities. RDFS simply not (being domain and range not restrictions just to clarify)

[no-reply]

I share the concerns expressed by @escowles in #53:

I am very skeptical of OWL: it is much more expressive, but also much more complex, doesn't help with validating that data conforms to the ontology, etc. IMHO, I think we should stick with simple RDFS, and rely on application profiles, good documentation, implementations, etc. to show how the classes and properties should be used together.

I'm interested in hearing OWL use cases, to better understand the motivation behind the suggested changes and how they might impact existing RDF(S) uses.

[azaroth42]

I also am skeptical of the benefits. I would be happy with RDFS + minimal basic OWL such as owl:inverseOf and other individually justified features.

[DiegoPino]

About those concerns @no-reply

I am very skeptical of OWL: it is much more expressive, but also much more complex,

True, more complex, but not too complex. skeptical is good, leads to further reading

doesn't help with validating that data conforms to the ontology, etc.

Not true. Does help validate a lot, more that just 'range' and 'domain', allows you to infer new classes based on rdf:type intersection, union, etc, restrict properties to certain subjects and objects class membership and also by quantifiers. And lastly, the profiles we are interested in are real time computable (finite time), which will never happen for RDFS.

Very quick example: (beware, i'm changing the original semantics of PCDM here, it's just an example, not the intention)

 <owl:Class rdf:about="http://pcdm.org/models#Object">
     <owl:hasKey rdf:parseType="Collection">
       <owl:ObjectProperty rdf:about="hasUUID">
       <owl:ObjectProperty rdf:about="originatingServerURL">
     </owl:hasKey>
     <owl:equivalentClass>
          <owl:Restriction>
              <owl:onProperty rdf:resource="http://pcdm.org/models#hasFile"/>
              <owl:allValuesFrom rdf:resource="http://pcdm.org/models#File"/>
         </owl:Restriction>
         <owl:Restriction>
              <owl:onProperty rdf:resource="http://pcdm.org/models#isMemberOf"/>
              <owl:allValuesFrom rdf:resource="http://pcdm.org/models#Collection"/>
         </owl:Restriction>
     </owl:equivalentClass>
     <owl:disjointWith rdf:resource="http://pcdm.org/models#Collection">
     <rdfs:subClassOf rdf:resource="http://www.openarchives.org/ore/terms/Aggregation"/>
</owl:Class>

basically saying that an pcdm:Object can't be a pcdm:Collection at the same time, that when using
for subject pcdm:Object predicate http://pcdm.org/models#isMemberOf, the Object of the triple can only be a pcdm:Collection, etc. And lastly that an individual of type pcdm:Object can be identified by an uuid + originating server URL mix.

I'm not saying that my example is what PCDM should be, not is this an OWL 2 primer(many out in internet, can suggest some readings if you want) but what i'm saying is that with the correct restrictive, permissive semantic language the data models that could be constructed out of PCDM could be a lot more specific and easily understood(and validated) by other systems, not only Hydra and Islandora by the way.

Hey, you could even create a pcdm:range Construct that does not need to be explicitly defined (nor used), just the class intersection of IIIF definition (predicates or classes) of range + pcdm:Object. OWL 2 is powerful and used.

Question: Does Hydra use Ontology reasoning somewhere? Or any semantic algorithms? maybe not?

http://www.w3.org/TR/owl2-primer/

[tpendragon]

So I don't know anything about OWL at all, and have a couple questions:

A) Is it hard to look at and explain? I assume the same documentation which pointed to RDFS before could point to OWL?

B) Is it hard to maintain? Is writing the first one so complex that it would take weeks or months of work and we wouldn't be able to work on implementation? We haven't changed PCDM in 11 months - if OWL would be so complex that a timeframe like that is unreasonable, then it's a good argument to stay with RDFS.

If the answer to those are both no, and @diego, @whikloj, and @ruebot are willing to put in the time to help develop an OWL ontology, I think we should - many of us seem to have a vested interest in it.

Question: Does Hydra use Ontology reasoning somewhere? Or any semantic algorithms? maybe not?

No. Does Islandora?

[no-reply]

@DiegoPino:

True, more complex, but not too complex.

This seems to be the subject of the ticket. Can we be more concrete about the use cases so we can judge the relative complexity cost?

I appreciate that you're trying to be helpful, but it honestly reads as more than a little condescending to suggest that this is an opportunity for introductory reading. It's also dismissive of the concerns.

To be more specific, I'm concerned that:

• the model theoretic overhead of OWL will make participation and implementation expensive;
• OWL would increase the cost of producing relatively simple descriptive metadata. I already hear complaints that domain/range have this effect (e.g. in Dublin Core). Many simply ignore it;
• in general, OWL (at least in certain profiles) is inappropriate for a low level structural model, on which higher level models (which may not be OWL, or even RDF) are built.

[azaroth42]

To put it a different way: In my opinion, people who want the ontology to change to OWL should describe the changes, and justify why they're individually useful in practice. Actual OWL examples rather than theoretical would be valuable.

[DiegoPino]

@no-reply sorry if it reads condescending, was not the intention, but all i see are concerns about OWL and no justification i can research on(documented somewhere or that helps me understand them)

I appreciate that you're trying to be helpful

reads on this side also condescending. Semantics everywhere 😄

I do feel there is a miss conception of what OWL is (in specific OWL 2, we haven't talked about profiles yet). It is simpler to reason on under certain Profiles, RDFS === OWL FULL == possible to never reach to a "NO" or "YES" under a given semantic proposition is more flexible but not good for machines.

I know you all are very semantic involved, but since i hope other people are reading this also i will paste this link (simple one) which pretty much explains why OWL

http://www.cambridgesemantics.com/semantic-university/rdfs-vs-owl

I'm not a PCDM committer so clearly i can't ask for a re-vision on your no-OWL policy, but i'm a CLAW Committer and i do work extensively with Semantics and graph traversal algorithms since fedora 3 times and this OWL versus RDFS dilema is not just a think of what each group likes more, it is about what will serve better fedora4 community, Hydra, islandora and i hope others, and will help making interoperability easier:

I see concerns but i don't understand the concerns, so here are my questions:

• the model theoretic overhead of OWL will make participation and implementation expensive;
  Participation in building the Ontology?

How does the Implementation of an rdfs ontology could be less expensive than of an OWL one?

• OWL would increase the cost of producing relatively simple descriptive metadata. I already hear complaints that domain/range have this effect (e.g. in Dublin Core). Many simply ignore it;

How does OWL interfere with descriptive metadata? OWL works at a different semantic layer, you are still using rdf:type, still can use dc:, etc. If OWL does not imposes a disjoint or a restriction that limits to just a set, then descriptive metadata and even extra rdf:types comming from rdfs classes if needed. Not that i would infer on them of course.

If domain and range already alienate people, then are we really ready to use any restricted model? Maybe we can just let anything happens.

• in general, OWL (at least in certain profiles) is inappropriate for a low level structural model, on which higher level models (which may not be OWL, or even RDF) are built.

Why is that so? How? LDP is low level, PCDM is structural but no as low level as you would wish. If already talking about "Works" and "membership to abstract concepts" like a collection then it is not low level anymore.

Use case here, i'm pretty sure @acoburn can add some more.

• Allow our users to define their own valid constructs based on PCDM but combining high level Semantics (PCDM can model a structure that servers for a book, but to say "this is a book" you need another ontology). Which leads to be able to traverse the PCDM Ontology, infer over it, ask if certain axioms validate, using restrictions on properties, etc, in realtime. Same goes of IIIF, etc.
• To be able to read a structure built by Hydra on Islandora without having to create a PHP class that implements the same properties/methods that Hydra does. If PCDM allows any construct and the Ontology itself does not imposes restrictions, then mapping gets complex - impossible. If PCDM defines a finite, simple sets of models (thats is what an ontology is, the domain of all models it is able to define, right now almost infinite) then we can do this.
• To be able to make inferences, inverse properties, graph traversal with precomputed paths
• Graph validation: does that graph coming into my Microservice (POST?) complies with PCDM?

I don't feel this is something we can push much longer as Islandora Community without feeling that we need to justify ourselves constantly when we do know, to certain extend of course, why we are proposing and talking about this stuff. I understand that there are concerns of course and i'm trying to understand them.

[cmharlow]

Heya! Sorry, complete outsider questions / thoughts here. I don't really know where I fall now. So, indulge me for a second, I'm writing up here how I understand the question at hand as well as the possible answers, and the pros/questions of each answer. Please correct me if I'm wrong - and I'm sorry if I misinterpret something!

q: Should PCDM use some flavor of OWL or stick with RDFS?

possible answers:

1. Stick with RDFS.
   • pros: lower barrier to community engagement in understanding, expanding + adopting PCDM because RDFS is "simpler"; it is currently used; it lowers the bar of implementation bc it is "simpler", but 'easier' implementation is then scoped to the currently existing, limited expectations of RDFS; it is meant to be a low-level model to then build upon.
   • my own questions:
     • Do we have any documentation from the origins of PCDM that detail either the original community goals (including what I'm hearing as simplicity for the sake of broader community engagement or low level modeling) and maybe even earlier discussions on RDFS versus other (OWL?)?
     • I.e., do we have the discussions that led to RDFS to begin with? Being someone who wasn't there at the origins of PCDM (granted I'm rarely at the origin of anything), I'd hate to second guess at the reasoning why. These sort of notes/docs might help clarify and avoid any sort of chicken and egg issues around 'RDFS bc its all we need' 'all we need is RDFS' type understandings.
2. Stick with RDFS, but include some OWL assertions as needed.
   • pros: includes all the pros of 1., but adds extra specificity for PCDM resources as needed.
   • my own questions:
     • does the use of OWL assertions as needed in RDFS support in any way the pros of OWL without declaring OWL? Say, can you perform inference on RDFS ontologies that then have OWL components?
     • Can you perform validation? Other sort of RDF Logic rules like SWRL? I genuinely don't know and would be curious to find out.
3. Go with OWL (flavor TBD but likely OWL2 from the discussion so far - is this a safe assumption?)
   • pros: you gain all of the possibilities of OWL 2 for more granular control, understanding and manipulation of your data, such as inferencing and validation; it helps the community by supporting conformance to the understandings of PCDM (so one won't just read what an Object is, but have to follow some usage rules defined by the community as to how Objects behave).
   • my own questions:
     • I am curious what specifications we'd want to immediately using an OWL version of PCDM for - what is so granular that we want to capture it now in the core PCDM ontology, versus what is a data goal we are aiming for?
     • As a data person, I love the idea of some kind of validation, but I also wonder how much of that I'd want to be in some sort of validated application profile in the application layer. I torn on this. Is this validation referred to - is this SHACL? If so, is SHACL in any state to be used now if you're not a W3C working group member with an instance of TopBraid?
     • I also wonder about the distinct possibility that more complex definitions (even if not really that complex) will lead to more people ignoring those definitions, i.e., more bad data. And if we take bad data into consideration for these discussions.

I'm also wondering, rather generally, about any directions we're hoping to aim for with PCDM, as this discussion has hit quite a bit on the reasons for and why PCDM. Directions wouldn't just be immediate goals, but also long term directions. Also, do we have any PCDM users who are not using Fedora? Was NYPL in that camp? I'd be very curious to hear their thoughts.

Thank you everyone for your comments - I appreciate them! I always a learn a lot from all of you, and I'm sorry if my above comments/questions miss any points, or have silly questions.

[scossu]

There are several threads on the API-X topic (here is one of them) about how using OWL to validate data is a bad idea. There are some specific vocabularies such as SHACL to express that.

I can appreciate the huge expressive potential of OWL but I am wary of the barrier it would set. Our Blazegraph instance is already starting to slow down on 15M triples with inference on, even without any OWL axioms loaded.

I second @no-reply about gathering use cases and I think that adopting RDFS (or even RDFS+ as @azaroth42 suggests, if needed) would leave room for plenty of expressiveness. Stepping up to OWL at a later time if needed, or even better, letting an individual adopter add their own OWL ontology on top of PCDM, is logically straightfoward; the opposite is much harder.

Also, I recall PCDM being originally conceived to express basic structural relationships between resources and to be a "minimum common denominator" for richer ontologies that can be overlaid on top of it. I believe that a very expressive ontology may lead into maintenance headaches, development slow-downs and the temptation to use PCDM for what is not meant to do.

[escowles]

The main things I've heard as use cases for OWL are:

• declaring pcdm:hasMember/pcdm:memberOf as inverse predicates
• declaring pcdm:Object/pcdm:Collection/pcdm:File as disjoint classes

I hadn't heard of RDFS+ before, but it sounds like we could layer those kinds of OWL statements on top of the RDFS ontology. That seems really attractive to me, but I really don't know enough about RDFS+ to know if that's practical or useful.

[escowles]

@cmh2166: I think we went with RDFS mostly because it's simpler and covers the use cases we had in mind when we started drafting PCDM. I don't think there's any good documentation of that decision, but I have always thought of the second paragraph of the main PCDM document (now the wiki home page) to be a call to favor simplicity, and to justify complexity when it's needed:

To encourage adoption, this model must support the most complex use cases, which include rich hierarchies of inter-related collections and works, but also elegantly support the simplest use cases, such as a single user-contributed file with a few fields of metadata. It must provide a compact interface that tool developers can easily implement, but also be extensible enough for adopters to customize to their local needs.

That said, to @tpendragon 's question, I don't think OWL has to be any harder to read or understand than RDFS. Fedora's core ontology is an example of a mostly simple OWL ontology. However, notice that it does let you do some interesting things that wouldn't map easily to RDFS.

[cmharlow]

Thanks @escowles - I was sure the decision docs were there, I was just trying to lay this question out methodically for my own understanding. :-/

Thanks @scossu for the additional links and bringing up the issue of performance. Also I really appreciate/agree with this statement:

Stepping up to OWL at a later time if needed, or even better, letting an individual adopter add their own OWL ontology on top of PCDM, is logically straightfoward; the opposite is much harder.

So the state of this question as I understand it:

Possible options:

Stick with RDFS.
pros:

• lower barrier to community engagement in understanding, expanding + adopting PCDM because RDFS is simpler (fewer classes, predicates; less possible other logic to add);
• it is currently used as it fit the original use cases for PCDM;
• it lowers the bar of implementation bc it is simpler, meaning more efficient / possibly more performant with large datasets.
• it is meant to be a low-level model to then build upon.

RDFS+ i.e. include some OWL assertions as needed
pros:

• includes all the pros of 1 (I think? Would it still be as performant?)
• adds extra specificity for PCDM resources as needed.
• needs to be confirmed how helpful this is, i.e., what is added other than the ability to use some more granular statements (i.e. inverses, disjointness)

Go with OWL (flavor TBD but likely OWL2?)
pros:

• you gain all of the possibilities of OWL 2 for more granular control, understanding and manipulation of your data, such as inferencing and validation;
• it helps the community by supporting conformance to the understandings of PCDM including restrictions.

The given (so far) Use Cases (term used loosely) for something more than RDFS:

• declare inverses of properties in PCDM
  • examples: pcdm:hasMember/pcdm:memberOf
  • could do this in options 2 or 3
• declare disjointness of core Classes
  • examples: make pcdm:Collection, pcdm:Object, pcdm:File disjoint
  • could do this in options 3 only
• allow users to define their own valid constructs based on PCDM but with other semantics
  • examples: Creating a profile for a book - do we have more about this example? It might help discuss whether validity checks to this degree happen in the ontology or elsewhere (SHACL, in the application, etc.)
  • could do this ... only in option 3? Becomes question of using OWL to validate or other logic languages, per @scossu's shared other discussion.
• to capture community-shared restrictions/behaviors in the model instead of in the applications using the data
  • examples: Islandora won't need to recreate in PHP some of the Hydra Ruby code for implementing shared understandings of the data. That's how I'm reading this. I'm sure there are, but do we have examples of this, behaviors that apply to the model, are expected by anyone using PCDM, but are expressed in the Hydra code?
  • could be 2 or 3, depending on what exactly these are, which I think goes to the call for more examples/use cases.
• better (?) inferencing
  • at a performance cost
  • example: what would we want to get specifically from OWL2 inferencing if we could implement OWL tomorrow?
  • only 3?