Time/Place
This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:
Attendees
Agenda
- Art Institute of Chicago use case
- Expose primary-type via F4 API?
- Hydra Connect plans
- See Hydra Connect 2014 Agenda.
- 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