From Filtered Push Wiki
Jump to: navigation, search

Etherpad for meeting notes: http://firuta.huh.harvard.edu:9000/FP-2011Dec06


  • Report from iDigBio
  • NSF Workshop RFP
  • Tech Issues

Carry To Next Week

  • Reports from iDigBio presentation (James)
  • NSF Workshop RFP
  • Pending Tech Issues
    • FilteredPush Requirements Report_on_FP_Requirements
    • Tech group needs to make a decision on or set a date for decision for the query language for pub-sub for Apple Pie.
    • Tech group needs to make a decision on or set a date for decision for the domain objects supported for Apple Pie.
    • Tech group needs to decide on or set a date for decision for the scope, composition, and implementation of the "global cache."



FilteredPush team meeting 2011 Dec 06

Present Lei, Jim, Maureen, Paul


  • Report from iDigBio
  • NSF Workshop RFP
  • Tech Issues


Jim: iDigBio James gave good overveiw in summary. Main message, we need to deliver functionality, if system works as intended, then we can expect serious consideration for its use by iDigBio. Best course is to continue what we are doing.

NSF Workshop RFP, no news from Jim, check with Bob if he should resend any emails to Jim.

Maureen: Anything Lei needs for us.

Lei: Working on the specify code. Looking for a place for the mapper to talk with their persistence layer.

Maureen: Look at workbench?

Lei: Yes, not in great depth.

Paul: Conversation with specify team this morning is relevant.

Maureen: String formatting, e.g. of loan numbers, in specify, if write into database avoids the buisess rules that manage the string formatting, then (current) specify will crash on encountering data that don't match the formatting rules.

Lei: Question: Should we be trying to generate sql against specify , as current specify version doesn't have clean separation of buisness logic, UI, and persistence layers.

Maureen: Looking through workbench to evaluate how easily something could be teased out for use by the mapper.

Maureen: for Example: Get next catalog number - rule for format of catalog number is embedded in code/configuration, result stored in database as string, e.g. year+constant+next number in sequence.... This information isn't configured to be available to the database layer.

Maureen: Suggest we start with an interface that sits above the sql, opposite direction of OAI.

In network collection object is set of fields in simple darwin core. We can say with rules that this set of fields comprises a collection object.

Locally, specify has another set of fields that represent the collection object (again abstraction like darwin core, mapper needs to map between network and this representation. Then there's a driver that maps between this intermediate representation and the local database - implementation left to local db system.

Working on a baby implementation of this, with a configurable definition of a record. Job of the mapper to match the record definitions from both sides.

Maureen: here is the API for the Mapper Driver: boolean saveOrUpdate(String type, List<Field>)

Where the return value is true if the operation succeeded.

Where type is one of:

Occurrence Event Location (dublincore) GeologicalContext Identification Taxon ResourceRelationship MeasurementOrFact

And a Field provides:

String getName() String getValue()

And field names are SimpleDarwin terms.

Here is one more method in the Mapper Driver API:

This is how the the mapper can find out if the object exists in the local database: String get(String type, List<Field>)

The list of fields is like a set of criteria to match, the String returned is a non-empty identifier if a match existed.

Lots of discussion. Summary in white board diagram.
lower level mapper interfaces
Annotation passing through mapper

Defer other agenda points to friday.