Islandora Ontology

[Nick Ruest]

Hi folks-

While working on the migration mappings for fcrepo3->fcrepo4 properties,
I documented all known RELS-EXT and RELS-INT predicates in the Islandora
7.x-1.x code base[1]. The predicates came from two namespaces; fedora[2]
and islandora[3].

The fedora namespace has a published ontology[4] that we use --
relations-external -- and that can be referenced. However, the islandora
namespace did not have any published ontologies associated with it.

That said, I have worked over the last couple of weeks with some very
helpful folks on drafting initial version of Islandora RELS-EXT and
RELS-INT ontologies, and the Islandora Roadmap Committee voted that it
should be published. The published version of the RELS-EXT ontology can
be viewed here[5], and the published version of the RELS-INT ontology
can be viewed[6] here. In addition, the ontologies were drafted in rdfs,
and include a handy rdf2html.xsl to quickly created a publishable html
version. This available on GitHub[7].

What does this all mean?

We have now documented what we have been doing for the last number of
years, and we have a referencable version of our ontologies. In
addition, this is extremely helpful for referencing and documenting
predicates that will be apart of an fcrepo3-fcrepo4 migration.

What's next?

The initial versions of each ontology have proposed rdfs comments,
ranges and and skos *matches for a number of predicates. However, this
is by no means complete, and I would love to see some community
input/feedback on rdfs comments, ranges, additional skos *matches, or
anything else that you think should be included in the RELS-EXT ontology.


How to provide feedback?

I'd like to have everything handled through 'issues'[8] on the GitHub
repo. If you comfortable with forking and creating pull requests, by all
means do so. If you're more comfortable with replying here, that's works
as well. All contributions are welcome! The key thing -- for me at least
-- is to have community consensus around our understanding of these
documented predicates :-)

License?

I have not licensed the repository yet. I had planned on using the
Apache 2.0 License as is done with PCDM[9], but I'd like your
thoughts/opinions on proceeding before I make a LICENSE commit.

Questions?

I hope I have covered it all. But, if you have have any questions, don't
hesitate to ask.

cheers!

-nruest

[1]
https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/migration.md#fcrepo3-rels-ext-to-fcrepo4-mapping
[2]
https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/fedora-namespace-predicates.md
[3]
https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/islandora-namespace-predicates.md
[4] http://www.fedora.info/definitions/1/0/fedora-relsext-ontology.rdfs
[5] http://islandora.ca/ontology/relsext/#
[6] http://islandora.ca/ontology/relsint/#
[7] https://github.com/Islandora-Labs/islandora_ontology
[8] https://github.com/Islandora-Labs/islandora_ontology/issues
[9] https://github.com/duraspace/pcdm/blob/master/LICENSE

[Nick Ruest]

1. I'd ask the compound solution pack maintainer(s)/designer(s).

2. Those are from the image annotation solution pack.

3. If I'm understanding it correctly, those are for OpenSeagragon and
Internet Archive Bookreader. As for using existing predicates in
existing ontologies, couldn't agree more. But, this is just documenting
what we are doing now, and adding commentary/matching where we can.

-nruest



On 2015-05-21 12:47 PM, Mark Jordan wrote:
> Hi Nick,
>
> An impressive piece of work! Very, very useful, as you say.
>
> I have a couple of questions
>
> 1) In the RELS-EXT ontology, why do we include the PID in
> isSequenceNumberOf$escaped_pid instead of using the PID as the object of
> isSequenceNumberOf?
>
> 2) What are http://islandora.ca/ontology/relsext/#targets and
> http://islandora.ca/ontology/relsext/#targetBy ?
>
> 3) In RELS-INT, height and width seem strange properties, for one reason
> because they apply to images only. Since they are exact matches to two
> corresponding existing properties, maybe those should be used instead
> and these properties deprecated in F4.
>
> Mark
>
>
> ------------------------------------------------------------------------

> --
> You received this message because you are subscribed to the Google
> Groups "islandora-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to islandora-de...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "islandora-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to islandora-de...@googlegroups.com
> <mailto:islandora-de...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Nick Ruest]

By all means, the goal in the 7.x-2.x project is to take advantage of
PCDM, and contribute back to PCDM where we see any deficiencies, and or
gaps in how we have implemented things. I'll most likely be spending a
fair bit of time in June (in between conferences and time off) on
continuing to model our existing 7.x-1.x content models (solution packs)
in PCDM. This will probably be lots of diagrams and tables. I have a bit
already, but I'd love to have more, and I'd also love to work with folks
on it willing to devote the time.

All that said, in an ideal world, the existing Islandora ontologies
(relsext/relsint) could be deprecated, and mapped/migrated on to
existing ontologies. However, Islandora Ontology will still exist as
documentation of what we are currently doing (7.x-1.x), and also serve
as a bridge in migrating from fcrepo3->fcrepo4. Depending on how things
play out, the mapping/migrating of predicates can be done during the
migration, or be done post migration. We'll just need some community
consensus around that.

...and not to confuse folks with even more tables. The most
current/accurate table of predicate mappings exists in the Migration
Utilities README[1]. As we implement things there, the table will be
updated. (Big thank you to Mike Durbin and Danny Lamb for all of their
wonderful work on that utility!)

-nruest

[1] https://github.com/fcrepo4-labs/migration-utils#property-mappings

On 15-05-21 06:45 PM, Robin Dean wrote:
> Mark, thanks for your comment about core vs. solution pack ontologies. I
> would further suggest that we try to use PCDM as the Islandora core
> ontology.
>
> Is there anything that an Islandora core ontology would do in Fedora 4
> that PCDM doesn’t cover? (Nick’s Fedora 3 > 4 mapping [1] will help us
> figure this out.) If we do find anything in the old Islandora ontology
> that PCDM & Fedora 4 can’t handle, I would prefer to change or extend
> PCDM rather than make a separate Islandora core ontology.
>
> I agree with the general principle of using existing predicates from
> other ontologies wherever possible to create Islandora F4 functionality,
> rather than making new predicates specific to one solution pack or
> viewer. But if we do make new predicates, it would definitely be good to
> document then in separate ontologies that are associated with the
> solution packs that use them.
>
> Robin
>
> [1]
> https://github.com/Islandora-Labs/islandora/blob/7.x-2.x/docs/technical-documentation/migration.md
>
> *From:*island...@googlegroups.com
> [mailto:island...@googlegroups.com] *On Behalf Of *Mark Jordan
> *Sent:* Thursday, May 21, 2015 11:50 AM
> *To:* island...@googlegroups.com
> *Subject:* Re: [islandora-dev] Islandora Ontology
>
> ------------------------------------------------------------------------

>
> 1. I'd ask the compound solution pack maintainer(s)/designer(s).
>
> 2. Those are from the image annotation solution pack.
>
> 3. If I'm understanding it correctly, those are for OpenSeagragon and
> Internet Archive Bookreader. As for using existing predicates in
> existing ontologies, couldn't agree more. But, this is just documenting
> what we are doing now, and adding commentary/matching where we can.
>

> OK, thanks. Just a general comment though.I'd much rather see that for
> the F4 version of this, we include the core Islandora properties in one
> ontology and solution-pack specific ones in their own (one per solution
> pack). That way, it will be easier to maintain the core ontology since
> it won't need to be updated for new solution packs (or changes in
> existing ones), and solution packs that aren't part of the standard
> Islandora suite can have their own as well.
>
> I present this suggestion here for discussion only, but having
> solution-pack-specific properties in the core Islandora F4 ontology
> seems a bit monolithic.
>
> Mark