Skip to content
Aaron Coburn edited this page Sep 14, 2016 · 15 revisions

Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join. Here is the info:

Attendees

  • Nick Ruest
  • Danny Lamb
  • Natkeeran Kanthan
  • Marcus Barnes
  • Caden Armstrong
  • Aaron Coburn
  • Ryan Townshend
  • Jared Whiklo
  • Melissa Anez
  • Ed Fugikawa
  • Kim Pham ⭐
  • Audrey Templeton

Agenda

  1. RDF Inference, part 1:
  • What is inference?
  • What is simple RDFS Entailment?
  1. API-X? See this
  2. September Sprint; September 19 - October 3
  1. Fedora Import/Export sprint
  1. ... (feel free to add agenda items)

Minutes

irc log

1. RDF Inference

  • Talk about OWL and inference on IRC, questions about it

Aaron:

  • Inference

    • If you have an RDF graph, the whole point of inference is to take existing RDF triples and make more triples. For instance if a resource has this triple: <> dcterms:title "A Title"@en ., we know via inference, that we also have this triple: <> dc:title "A Title"@en .. That is because dcterms:title rdfs:subPropertyOf dc:title.
  • RDFS entailment

    • RDFS is a small vocabulary, 4 relevant properties - rdfs:range, rdfs:domain, rdfs:subClassOf, rdfs:subPropertyOf using SKOS vocab and using skos:broader, note in ontology if domain skos:Concept and range skos:Concept, not in subject or object
    • With RDFS entailment (a kind of inference), without stating that a subject resource is a skos:Concept we know that it is because it's using skos:broader with rdfs:domain and rdfs:range skos:Concept
    • thus an additional triple rdf:type appears
    • with RDFS entailment in a lot of cases, you don't need to indicate an rdf:type of a particular resource, in a lot of cases it's inferred
    • you have a minimal graph that contains all semantic meaning of entailed graph, and you don't need to include all of the triples because it's going to be inferred

Danny: OOP terms, is this something that could be essentially used if you say that a domain of a property is a deep down sub-class, pcdm:Object e.g. and you give property islandora:image, saying you can pass in a child class and it would understand that?

Aaron: If you're using simple RDFS it gets more complicated with OWL union sets. you don't have to pass in anything in terms of types. e.g. some resource pcdm:hasFile you don't have to use PCDM file or object or any of those because they're all inferred

Danny: & you don't have to put them in fedora? (no)

Danny: how about polymorphism, a service that works on ore:aggregates, instead provide to that service a way to look for all infant PCDM objects

Aaron: API-X service binds to ore:Aggregation. your resource uses pcdm:hasMember but we don't use PCDM classes at all. In RDFs entailment pcdm:hasMember is a subclass of ore:aggregates, with pcdm:Object domain, ore:Aggregates domain for ore:aggregation. For pcdm:hasFile via inference (API-X) you will know that that resource is in fact an ore:Aggregation

Danny: can you catch the inference from something else entirely?

Aaron: Sure. The inference engine needs to be fed this information (e.g. owl:imports, load ontologies into triplestore, in code)

Danny: What is the cutoff point where RDFS entailment not enough? need to use something more complex?

Aaron: API-X has a particular service that binds to an ore:Aggregation, can use RDFs entailment to get to an aggregate. To bind to more complicated entities, e.g. an ore:Aggregation that has at least 5 pcdm members, subject is individuals or list of authors. Not taking just the type of object but also structural characteristics. A complete object could have a skos:prefLabel, dcterms:subject etc. you can use an owl:Restriction, restrict objects that meet the following criteria = structural typing.

Danny: If we wrote our own ontology for our own types of objects, unless we want to validate/confirm structure we could get away with just RDFS?

Aaron: For most ontologies where you describe a hierarchy of properties/subproperties classes/subclasses, RDFS pretty complete. For defining structural typing you would need OWL for something more expressive. Lots of triplestores support RDFs, some OWL. Full OWL is computationally expensive.

Aaron: Certain classes of OWL FULL are theoretical, no actual full Free open source implementation

Jared: so do you see a need for OWL for PCDM? or just RDFS

Aaron: PCDM could use some OWL, pcdm:Collection can have pcdm:hasMember to an object, but pcdm:Object can also pcdm:hasMember to pcdm:FileSet or file. Once you start to introduce "or" operators, things get complex, OWL comes in here

e.g. pcdm:hasMember to some other resource, what can I say about those two things if I know that the object is a collection? in principle you can infer that the subject is also a collection, if subject is a pcdm:Object should be able to infer this. Right now it falls back on ore:aggregates.

Jared: So a collection in PCDM can hold an object or another collection, object can hold an object but not hold a collection.

Aaron: pretty sure in OWL you can enforce this (where's Diego when you need him?)

Danny: even though at this point triplestore doesn't drive display, performance wise is it hog to use a triplestore (e.g. Fuseki)?

Aaron: You could cache it. Use as few triples as possible in fedora, when a new resource is created message goes out, triplsetore populated, get callback, query entailed graph (rather than minimal) do stuff with JSON-LD,get cached with document store/Drupal and what will drive the downstream application.

2. API-X? See Issue on GitHub

Danny: At first general interest but there was no definitive confirmation if we're going to use it. API-X all comes down to notion of microservices, small services but if you have them working on Fedora resources then it's tightly coupled with that, not good. You make small services that work on things like imagemagick convert etc. endpoint to post an image spitting out a thumbnail service. To invoke that service on a Fedora object, use API-X. API-X is a proxy that sits in front of fedora, with additional routes added, path to resource but then /thumbnailservice will actually go and pull out of fedora, pass it to small little service that works on images.

Breaks services apart. Can be a component for registering/unregistering services. Make a new route to pass object to fedora, which is an extension. You can bind extensions to services with API-X, which has profound implications - e.g. derivative generation from preservation master by working on object and passing it to fedora

Danny to all: Asked about API-X on GitHub, CLAW committers approve, asking for additional opinions.

Jared: worse case scenario Archivematica format policy registry service, best case scenario anyone can write service in spec and plug it in.

Danny: e.g. FITS server, want to execute on Fedora resources. It standardizes us to something and service oriented architecture principles

Action: We're going to use it

3. September Sprint; September 19 - October 3

Danny:

Sprint priorities:

Nick:

Danny:

  • sign up participate in discussions you do not necessarily need to code

4. Fedora Import/Export sprint

Nick:

  • report out about phase I
  • next week monday-friday, Penn State Sprint: we will be working on the project again. Esme, Nick, Andrew Woods, Jon Stroop, Adam Wead working on bugs, also starting phase II - BagIt support
  • everyone please feel free to keep an eye on it, also invitation to become a stakeholder, become a tester

End: 13:45 EDT

This is an archive. For new Tech Call notes, click here

⚠️ ARCHIVED Islandora Tech Calls

⚠️ ARCHIVED Islandora User Calls

Clone this wiki locally