2012Apr11

From Filtered Push Wiki
Jump to: navigation, search


Etherpad for meeting notes: http://firuta.huh.harvard.edu:9000/FP-2012Apr11

Agenda

  • Repository reorganization
  • Collaborations/Potential Collaborations
  • VM/Appliance Resource offer by iDigBio
  • SPNHC
  • State of Ecosystem components
    • Firuta configuration.
    • Client helper: Annotation generation.
    • Integration with Morphbank.
    • AnnotationProcessor: Specify Driver.
    • FP Access point API and FP Network Nodes.
  • Pending non-tech issues
    • Discussion of potential grant proposals.
    • Collaborations
  • Pending Tech Issues
    • Packaging Structure
    • API For Query and Cluster Finding
    • 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 decide on or set a date for decision for the scope, composition, and implementation of the "global cache."
    • Tech group needs to document the use, roles, and rationales for identifiers.
      • Who is responsible for MessageIDs and what purposes do they serve.
      • Identifiers in messages
      • Identifiers in annotations

Reports

  • Bob
    • Work with Paul on new new georeference rdf example
    • Looking over Paul's shoulder on publication representation of foaf:Person for biologists by name.
    • Begin to clean dwcFP


Notes

Filtered Push Team Meeting 2012 Apr 11

Present: Bertram, Maureen, David, Paul, Bob, Jim, James, Lei.

Agenda:

  • Repository reorganization (See below)

Maureen: Need separate projects again for working on separate components. Discussed on Friday, results below. Will discuss again.

  • Collaborations/Potential Collaborations

Nothing currently in our ball park.

  • VM/Appliance Resource offer by iDigBio

Slowly moving discussion.

  • SPNHC

Abstracts. Who to deliver? James and Paul.

Who to submit? Paul.

Who is going to SPNHC? At least Jim, James and Paul.

Team Meeting: Might be prefereable to have dedicated team meeting during the summer, either in Cambridge, or Davis.

Grant planning timing?

Tentative team meeting (grant planning/grant writing) In Boston/Cambridge 16th 17th June.

Tentative team meeting (advancing technical front) in Davis, in ?July.

Review James' one page google doc stake in the ground for proposal scope, sent out by email.

  • State of Ecosystem components
    • Firuta configuration.

Maureen: Morphbank and (Symbiota with test data from FSU ) installed on firuta. Currently accessible globaly with username/password.

No glassfish on Firuta yet.

Tech group needs to discuss how to deploy changes to firuta.

    • Client helper: Annotation generation.

David: Modifying web service to allow integration with either Morphbank or Symbiota.

Can generate rdf/xml and can submit to network access point.

    • Integration with Morphbank.

No recent changes.

    • Integration with Symbiota

David: Test copy up with test data. Form processing code located.

    • AnnotationProcessor: Specify Driver.

No recent changes.

    • FP Access point API and FP Network Nodes.
    • Data

James: Before long we should be looking at getting data from herbaria and doing duplicate finding.

Lei: Deploying test version of Components, still having integration/configuration issues.

Bob: Question about current state - two containers?

Bob: Scheduling questions: (1) DataOne - we should study their API and talk with them again - after reorganization. (2) DwCFP needs cleaning up - or commit to DwC-SC.

  • Pending non-tech issues
    • Discussion of potential grant proposals.
    • Collaborations
  • Pending Tech Issues
    • Packaging Structure
    • API For Query and Cluster Finding
    • 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 decide on or set a date for decision for the scope, composition, and implementation of the "global cache."
    • Tech group needs to document the use, roles, and rationales for identifiers.
      • Who is responsible for MessageIDs and what purposes do they serve.
      • Identifiers in messages
      • Identifiers in annotations


Repository Reorganization

First off: we are prepared to change the following strategy when it seems appropriate. Secondly: this strategy is up for change even before it is implemented.

A top-level "svn project" is a set of documents that in a folder that a) usually appears in a folder directly under our repository root, b) can be independently branched and tagged, and c) represents a unit of work that is self-contained, in the sense that a party from outside Filtered Push who is interested in some aspect of our project would find all documents they might intend to modify inside that project folder, and would not have to wade through much else that they would consider irrelevant. As a self-contained unit of work, projects that contain source code will also d) be represented by a packageable artifact, such as a Java jar/war, so they can be easily referenced (as in a Maven pom).

Once such a project is retrieved from the repository, there may be several ways to organize the included documents, such as in an Eclipse project, a Maven project, a Bouml project, etc. For the time being, we are going to include Eclipse .project and .classpath files in some of these subversion projects, so developers should take care not to check in files that won't work on someone else's machine.

One exception to this definition is the FP-Deployment project, which will serve to contain assorted descriptions of deployment configurations. In this case, the project is created as a place to keep those descriptions under version control, and nothing else. Deployments are expected to be groups of files related to building certain types of nodes, and would have dependencies on artifacts from other of our svn projects. Because the dependencies are expected to be quite broadly cross-cutting, there is no particular project in which they would find a suitable home.

Two caveats to a) are for work on "drivers" and "messaging." There is currently code for one particular driver, the Specify driver, and there is expected to be code for a "generic" SQL driver, and eventually, there may be drivers for other platforms. These code bases are independent, but will be grouped under a folder in the repository root named "FP-Drivers." In this case, the "svn projects" for each of these code bases would go into subdirectories of FP-Drivers as so:

root/FP-Drivers/FP-SpecifyDriver/{trunk,tags,branches} root/FP-Drivers/FP-SQLDriver/{trunk,tags,branches} ...

Similarly, since we expect an initial implementation of "messaging" based on key-value-pairs will be replaced by one based on Sparql, we would define those projects as so:

root/FP-Messaging/FP-Messaging-KVP/{trunk,tags,branches} root/FP-Messaging/FP-Messaging-Sparql/{trunk,tags,branches} Will this raise any issues if we wish to support both in the same network? (Is that meaningful?)...Bob


First, we are going to create the following top-level svn projects. Each will have subdirectories named trunk, tags, and branches. Each should also contain a readme that at minimum describes the scope of the project and how to set up a development environment for it, and if appropriate, how to build its artifact(s).

FP-AnnotationProcessor (0) FP-API-Library (1) FP-Deployment (2) FP-Messaging (3) FP-Node (4)

Here is a list of existing folders in the repository, and their intended dispositions. Please read phrases such as "this code will be moved to <svn project>" as shorthand for "this code will be moved to an appropriate subdirectory of <svn project>/trunk." How does this work for existing branches or tags of an existing svn project.

FP-Design : This stays where and as it is. It needs a readme (5). Bouml model code from FP-Network/trunk/design will be moved into FP-Design (6).

FP-GG: This stays where it is. It needs a readme (7).

FP-IPT: This stays where it is. It needs a readme (8).

FP-Mapper: This project will be removed (9). The code contained in it will be moved to FP-Drivers (10).

FP-Network: This project will be removed (11). The code contained in it will be moved to new svn projects as described later in this document.

FP-Tools: This project stays where it is. It needs a readme (12).

FP-Web: This project will be removed (13).

FP-WebUI: This project will be removed (14).

FP-specify: This project will be removed (15).


FP-Network/trunk/api: The parts of this that Lei needs for the annotation processor should be moved into FP-AnnotationProcessor (16), and the parts Maureen needs for the driver should be moved into FP-Drivers/FP-SpecifyDriver (17). We will de-duplicate later (18).

FP-Network/trunk/design: These files will be moved to FP-Design (19).

FP-Network/trunk/etc: This code was for FP1. It will be removed (20).

FP-Network/trunk/hadoop-install: This code was for FP1. It will be removed (21).

FP-Network/trunk/impl: The parts of this that Lei needs for the annotation processor should be moved into FP-AnnotationProcessor, and the parts Maureen needs for the driver should be moved into FP-Drivers/FP-SpecifyDriver (22). We will de-duplicate later (23).

FP-Network/trunk/lib: These files will be removed from version control (24), and retained as references in dependency management configuration files where needed.

FP-Network/trunk/network: This code was generated from Bouml, and has already been moved into subdirectories of FP-Network/branches. It will be removed from trunk (25).

FP-Network/trunk/rdf: These xml files are for the "rdf handler" (org.filteredpush.rdf.handler). (26)

FP-Network/trunk/resource: This code was for FP1. It will be removed (27).

FP-Network/trunk/src: This code was for FP1. It will be removed (28).

FP-Network/trunk/test: This code was for FP1. It will be removed (29).

FP-Network/trunk/webapp: This code will go into FP-AnnotationProcessor and FP-Deployment (29).

FP-Network/trunk/webservice: This code was for FP1. It will be removed (30).

FP-Network/trunk/build-ontologies.xml: This file will be moved to FP-AnnotationProcessor (technically no longer needed) the new annotation generation code is in org.filteredpush.rdf.* and xml config for it is in the rdf directory (31).

FP-Network/trunk/build.xml: This file will be removed, but portions of the context may go into the build.xml files of other projects (32).

FP-Network/trunk/license.txt: This file will be copied into each "svn project" (33).

FP-Network/trunk/Readme: This file will be removed, but portions of the context may go into the readme files of other projects (34).

FP-Network/trunk/{.classpath,.project,.springBeans,build-old.xml,build_wsclient_lib.xml,h.jar,pom.xml,w.tar.gz,wsbuild.xml}: These files are for FP1 and will be removed (35).


FP-Network/branches/EJBProjects/FP_API_Library: old NetBeans project replaced by new Maven/Eclipse one in FP-Node(36)

FP-Network/branches/EJBProjects/FP_EJBModule: old NetBeans project replaced by new Maven/Eclipse one in FP-Node (37)

FP-Network/branches/FP-ClientHelper: Contains the annotation generation SOAP webservice that is invoked by morphbank. (38)

FP-Network/branches/FP-Node/trunk/FP_API_Library: This code will go into FP-API-Library (39).

FP-Network/branches/FP-Node/trunk/FP_EAR: This code will go into FP-Deployment (40).

FP-Network/branches/FP-Node/trunk/FP_EJBModule: This code will go into FP-Node (41).

FP-Network/branches/FP-Node/trunk/FP_JavaApplication: This code will go into JUnit test cases in appropriate projects, and the configuration into FP-Deployment (42).

FP-Network/branches/FP-Node/trunk/FP_MessagingEJB: This code will go into FP-Messaging/FP-Messaging-KVP (43).

FP-Network/branches/SPNHC_Demo: ? (44)

FP-Network/branches/TDWG2010AnnotationOntology: ? (45)

FP-Network/branches/TestFPWebServiceProject: ? (46)

FP-Network/branches/TestFPWebServiceProjectClient: ? (47)