Time/Place

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

• Time: 11:00am Eastern Daylight Time US (UTC-4)
• ReadyTalk:
  
  • U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
  • International toll free:
    
    • http://www.readytalk.com/intl
    • Use the above link and input 2257295 and the country you are calling from to get your  country's toll-free dial-in number
    • Once on the call, enter participant code 2257295
• IRC:
  
  • Join the #duraspace-ff chat room via Freenode Web IRC (enter a unique nick)
  • Or point your IRC client to #duraspace-ff on irc.freenode.net

Attendees

• Stefano Cossu
• Unknown User (escowles@ucsd.edu)
• Greg Jansen
• Michael Durbin
• Ed Fugikawa
• Osman Din
• Chris Beer
• A. Soroka
• Eric James
• Andrew Woods

Agenda

1. Art Institute of Chicago use case
   1. Expose primary-type via F4 API?
2. Hydra Connect plans
   1. See Hydra Connect 2014 Agenda.
3. OSGi update

Minutes

Primary Types in JCR and RDF: Art Institute of Chicago use case

AIC content modelling - want to specify primary type

Stefano provides background

• Fedora is the most promising system for their needs
• originally looked at F3, appealing feature is content model validation
• many million assets to manage
• eventually want to publish linked data w/SPARQL endpoint, points to F4
• JCR's ability to model content appeals, close to object oriented design, classes of content
• JCR types are not perfect, many limitations
  • useful for implementing policies by type
  • useful for restricting fields
• leveraging JCR validation may be shortest path, already implemented, curious about F4 plans in this area
• goal at AIC is to implement by mid 2014 or second half of 2014

Andrew

• we have expressed philosophical reluctance to exposing the underlying platform
• keeping Fedora-level as the abstract, no dependencies on JCR
• we are already significantly invested in ModeShape and JCR, so it seems like we just have to find right level of abstraction
• content modelling is something we've started working on, but this is an extension of what we have already done

Stefano - primary type is part of JCR spec

Chris - RDF has no notion of primary type, so this will create mixed notions

Adam - RDF has no way of distinguishing primary type as a type

Esme - We are already muddying this water by exposing existing primary types as rdf:type

Stefano - an argument on node creation would suffice to set initial primary type, this would avoid any problems in RDF update work flow, since RDF updates would never include primary type

Adam

• we could offer a type triple with an object which is primary type
• would also allow us to publish the type in RDF with distinction
• only one triple of primary type would be allowed
• lack of a primary type would imply nt:folder (i.e. normal fedora object creation)
• haven't thought through it beyond creation...

Stefano - creation would fail if mandatory field not provided

Adam - we have no way to express the primary type as distinct to the rest of the world in RDF

Andrew - queries would include several rdf:type triples and one of those would be primary type

Adam - you could discover the difference by following links

Chris - what is the use case again?

Andrew - mixin cannot be restrictive of fields

Stefano - mixins can only add functionality or data, one use case is preventing any children

Chris - sounds like validation

Stefano - restrictions are more useful for data modelling

Adam - people have been asking for this for years

Chris (in IRC) - raises issues of interoperability between Islandora and Hydra heads.. (paraphrased)

awoods: you have an islandora app running against fcrepo4 that uses primary types to declare things are islandorabjects or whatever
cbeer:  08:35 ] cbeer>     and islandorabject nodes require a couple different properties
cbeer:  08:35 ] cbeer>     this means you can't drop in a hydra app on top of that fcrepo4 repo
cbeer:  08:35 ] cbeer>     and have it operate against those islandora nodes natively
cbeer:  08:36 ] cbeer>     and that's something you can do in fcrepo3, because no type validation is preventing that

Stefano - ready to help implement and very committed to Fedora 4 work

Primary type discussion to continue on the list..

HydraConnect conference plans

Andrew

• Chris, Esme, and Andrew will be attending. Would like to discuss plans for the 2-3 sessions where Fedora will be part of focus.
• Wants to meet later to come up with a game plan..
• To meet Tuesday 2pm EST discussion of conference plans
• hopefully the conference program will be more clear

OSGi

Andrew

• the problem: integrate my jar with fedora, without building fedora
• being prototyped in the JMS indexer project
  • conveniently plug in a custom indexer as a module

Adam - good summary

Andrew

• JMS indexer currently deploys into servlet container, but doesn't use HTTP features
• no reason not to switch that into an OSGi container

Adam clarifies container meaning

• standalone java application, we wrote the main class, uses OSGi framework internally
• it is a limited container process that we wrote, with an embedded OSGi framework
• we are not presently starting up a JBOSS or equivalent

Andrew

• bundles in a directory get loaded into OSGi framework
• someone who creates a plugin service will include dependencies - simplifying measure for now

Adam

• give them a maven archetype to start from
• or let them manage the bundle content explicitly
• offer a construct or practice that makes it easy
• transitive dependencies are a feature of container products (dependencies between bundles) - however framework does not offer that..

New Actions