From relationships to ontologies: best practice example of community driven development

Transcription

1 From relationships to ontologies: best practice example of community driven development Rosemary Le Faive Giancarlo Birello Diego Pino Islandora Conference 2015, August 3-7, Charlottetown, PEI, Canada

2 rosiel/islandora_relationship_editor How do we edit the RELS-EXT?

3 Limitations Hard-coded possible relationships Usability wasn t ideal: Had to enter the PID manually, no autocomplete Difficult to visualize the relationships, files were uploaded in the wrong places.

4 rosiel/islandora_relationship_editor

5 rosiel/islandora_relationship_editor

6 rosiel/islandora_relationship_editor

7 rosiel/islandora_relationship_editor

8 Example: Relationship-driven display

9 islandora_relationship_editor forked from rosiel/islandora_relationship_editor module to add/edit/delete/view RELS-EXT relationships based on OWL/RDF ontology stored into DSID only 1 ontology no autocomplete simple viewer

10 islandora_relationship_editor

11 islandora_solution_pack_ontologies-7.x-dev forked from DiegoPino/islandora_solution_pack_ontologies-7.x-dev module to add/edit/delete/view RELS-EXT relationships based on OWL/RDF ontology stored into DSID multiple ontologies autocomplete restrictions only on class assignment no graph viewer: I m waiting Diego

12 islandora_solution_pack_ontologies-7.x-dev

13 islandora_solution_pack_ontologies-7.x-dev

14 AGROVOC and AGRONTOLOGY AGROVOC is a controlled multi-languages vocabulary covering all areas of interest of the Food and Agriculture Organization (FAO) Concepts, Terms and Relations Hierarchical relations: internal using broader/narrower Non-Hierarchical relations: external using AGRONTOLOGY AGRONTOLOGY is a specific property vocabulary separated from the thesaurus AGROVOC AGROVOC SPARQL Endpoint

15 Q &!A Taxon included in Darwin Core or model based Relationships graph viewer Internal or external vocabularies in autocomplete Linked Open Data Fedora 4

16 So what do you mean with Ontology? Ontology, as used in philosophy, means: theory of existence. Ontology is an explicit specification of a conceptualization. Ontology is a body of knowledge describing a domain, typically a common sense knowledge domain An ontology is a formal description of the concepts and relationships that can exist for an agent or a community of agents. It represents knowledge. We could see a human language as a type of Ontological commitment. Agent means (in our case) Islandora Object So a community of agents are Islandora Objects belonging to a same CMODEL Concepts and relationships are properties in our RELS-EXT DS

17 So we are already using Ontologies? Yes. Fedora Commons has one. Islandora also. Not every Ontology is born equal Some Ontologies only define vocabularies. We have the words, but we don t know in which context should we use them nor they intendend meaning Other Ontologies define taxonomies (hierarchies). We have a clasification (like a tree). But we have to use/give our personal knowledge, a.k.a domain, on relation time. Other Ontologies go further: They restrict (i.e., define) possible use of constructs used in the description of the domain. This last ones have advantages: We can share them and validate our concept of domain.

18 Enough Theory Ontologies Solution Pack uses Restricted, reasonable, Open World OWL Lite /DL OWL2 EL/QL&RL We asume: Our Solar System is Islandora (There is a bigger Universe out there) Every Ontology defines rules based on certain knowledge domain needs (one World) O.O. = Our CMODELS are considered Classes. CMODELS are related to other CMODELS using properties We restrict those properties to certain existence/quantity/etc definitions What does this allow us? To have multiple knowledge domains for the same limited set of CMODELS To validate our existing relations To restrict (rules) what users/automated sist., can do with our objects We can share our Knowledge with other sistems. LOD?

19 In Production Ontology

20

21 Reasoning and Graph traversal strategies using Islandora Based on ARC2 + Graphite + Ruler We store Ontologies as Datastreams inside Ontology CMODEL Objects. Every Class is named after a real Islandora CMODEL We link existing CMODELS to this special Objects We parse the OWL stream, extract classes, properties and relations. We apply chained Business Rules to compute what we can and cannot relate.

22 Visualizing Same previous approach: For each CMODEL we fetch it s associated Ontologies (plural) We get which relations are allowed between objects in the same Ontology We build a Dynamic (somehow complex) SPARQL query traversing the Graph (depth First) to draw all posible paths. We use Vis.js to display this graph

23 Examples (quick!)

24 Current applications & future uses We can show related objects without knowing in advance what relations are hardcoded in SP. We can make batch imports relations aware. We can deduce which objects should be connected to which in quantity, quality, etc. We can validate our data. Find contradictions, error. We can pivot our navigation. What if we don t want to navigate using Collection hierarchies? Maybe some users have a different notion of how data should be organized. Mapping, LOD, distributed graphs, etc.

25 Solr as aid (velocity over precision) Solr has!joins Sadly they only return the last joined document info (we don t get all chained objects) Managing nested documents is a pain.

26 Solr as aid (velocity over precision) But: Sometimes the last item is enough We can facet over a all objects included in a knowledge graph! Even using ajax We can prefilter and then apply our Sparql Most important: we can use Solr (better even Solr Cloud) to connect distributed repositories

27 Inverse ones I Diego (Object, REPO1) could state: I m Mario s (my real father at REPO2) son. But Mario could stay in silence! Partial relations means partial reallities. Very usefull when dealing with Autorithy Objects and Distr. environments If Mario says: i m diego s Father. We got a full Meaning.

28 Whats next (on the way) Lets expose services: Full Graphs JSON-LD Make ingest workflows (UI) based on valid Object -> Object relations Replace Mulgara Make object visualization (hierachy) an option based on Users need