repository-extension-services issueshttps://gitlab.amherst.edu/acdc/repository-extension-services/-/issues2018-10-09T15:57:27-04:00https://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/1RDF to MODS XML transformation2018-10-09T15:57:27-04:00acoburnRDF to MODS XML transformationThe `acrepo-xml-metadata` service is very minimal and is based entirely on XSLT. It should be 1) aligned with the MODS xml application profile and 2) set up to dereference remote URIs, importing the appropriate label/structure.The `acrepo-xml-metadata` service is very minimal and is based entirely on XSLT. It should be 1) aligned with the MODS xml application profile and 2) set up to dereference remote URIs, importing the appropriate label/structure.bseegerbseegerhttps://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/2The camel-blueprint-routes should be made into full bundles2016-06-28T19:24:19-04:00acoburnThe camel-blueprint-routes should be made into full bundlesThe routes defined in https://gitlab.amherst.edu/acdc/camel-blueprint-routes should be refactored into simple modules that exist as part of this repository. The `camel-blueprint-routes` repo should then be removed.The routes defined in https://gitlab.amherst.edu/acdc/camel-blueprint-routes should be refactored into simple modules that exist as part of this repository. The `camel-blueprint-routes` repo should then be removed.bseegerbseegerhttps://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/3Normalize ports2016-06-16T14:52:07-04:00acoburnNormalize portsThe default ports of these services are all over the place. They should be organized into a scheme that makes some logical sense.The default ports of these services are all over the place. They should be organized into a scheme that makes some logical sense.acoburnacoburnhttps://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/4Rework modules to conform to naming paradigm (-services-, -exts-)2016-06-30T15:06:00-04:00bseegerRework modules to conform to naming paradigm (-services-, -exts-)Rework the acrepo modules to conform to this paradigm:
1) use `-services-<name>` for OSGi services -- these are used by other camel routes (sort of like spring injection, but for OSGi) These should be independent of Fedora.
2) ...Rework the acrepo modules to conform to this paradigm:
1) use `-services-<name>` for OSGi services -- these are used by other camel routes (sort of like spring injection, but for OSGi) These should be independent of Fedora.
2) use `-exts-<name>` for Camel-based routes that work on particular repository services -- these are synchronous endpoints that expose HTTP (REST-based) endpoints.
3) use `-connector-<name>` for Camel-based listeners of repository events -- sort of like the things in fcrepo-camel-toolbox
Java package structure should reflect package id: ie, `edu.amherst.acdc.exts.fits` directory should have `/src/main/java/edu/amherst/exts/acdc/fits` structure. bseegerbseegerhttps://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/5Create a validation service2016-06-24T10:06:12-04:00acoburnCreate a validation serviceThis service should read a Fedora resource and confirm whether the object structure is valid. It would use `owl:Restriction` clauses and some kind of inference engine. Whether it works directly on the Fedora repository or the triplestore...This service should read a Fedora resource and confirm whether the object structure is valid. It would use `owl:Restriction` clauses and some kind of inference engine. Whether it works directly on the Fedora repository or the triplestore is an open question.acoburnacoburnhttps://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/6Create a service that accepts a ZIP file of content and ingests that content ...2017-09-24T06:33:33-04:00acoburnCreate a service that accepts a ZIP file of content and ingests that content into FedoraThis would be an ingest service, quite possibly using an external (e.g. Python) script.This would be an ingest service, quite possibly using an external (e.g. Python) script.https://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/7Create an export service2017-09-24T06:33:33-04:00acoburnCreate an export serviceThis service should start at "top level" repository resources, collecting all child resources and assemble them into a ZIP archive, probably following the bagit format. The resulting file should be suitable for pushing into a digital pre...This service should start at "top level" repository resources, collecting all child resources and assemble them into a ZIP archive, probably following the bagit format. The resulting file should be suitable for pushing into a digital preservation system.https://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/8LD Cache Service2017-09-24T06:33:33-04:00acoburnLD Cache ServiceThis is mostly addressed by !21 This is mostly addressed by !21 acoburnacoburnhttps://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/9create a acrepo-services-ldcache-file module for dynamic ldcache backend support2017-09-24T06:33:33-04:00acoburncreate a acrepo-services-ldcache-file module for dynamic ldcache backend supportEnable dynamic OSGi service loading of different LDCachingBackend implementations (rather then the current hard-coded File-based backend)Enable dynamic OSGi service loading of different LDCachingBackend implementations (rather then the current hard-coded File-based backend)acoburnacoburnhttps://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/10Create a generic activemq service2017-09-24T06:33:33-04:00acoburnCreate a generic activemq serviceThis would be shared across all of the `acrepo-connector-*` modules.
This can be used as inspiration: https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/tree/master/fcrepo-service-activemqThis would be shared across all of the `acrepo-connector-*` modules.
This can be used as inspiration: https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/tree/master/fcrepo-service-activemqbseegerbseegerhttps://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/11Build a PCDM object service2017-09-24T06:33:33-04:00acoburnBuild a PCDM object serviceThis would be an extension (`acrepo-exts-pcdm`) that interacts with the `acrepo-services-pcdm` service. Given a Fedora resource path, it builds an entire PCDM object graph, returning the complete graph in whatever format was requested (e...This would be an extension (`acrepo-exts-pcdm`) that interacts with the `acrepo-services-pcdm` service. Given a Fedora resource path, it builds an entire PCDM object graph, returning the complete graph in whatever format was requested (e.g. via the `Accept:` header).acoburnacoburnhttps://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/12Revamp acrepo-exts-template to use different templates2017-09-24T06:33:33-04:00bseegerRevamp acrepo-exts-template to use different templatesFrom comments in https://gitlab.amherst.edu/acdc/repository-extension-services/issues/4#note_739
The idea is to revamp this module to work with any supplied template. There would be a URL param that points to a template, so it's fle...From comments in https://gitlab.amherst.edu/acdc/repository-extension-services/issues/4#note_739
The idea is to revamp this module to work with any supplied template. There would be a URL param that points to a template, so it's flexible. Perhaps the default could be a mustache template, but others could be supplied via this param. Or we could have a cfg variable that has the URL of the default (mustache) and that could be overridden by a URL param, if the user wants.bseegerbseegerhttps://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/13Add testing mechanism to acrepo-exts-pcdm2017-09-24T06:33:33-04:00acoburnAdd testing mechanism to acrepo-exts-pcdmA real test will be in `acrepo-itests` and involve building an entire PCDM object in Fedora and then calling the extension and retrieving the entire graph. The pcdm extension should also be added to the AcrepoServicesIT test.A real test will be in `acrepo-itests` and involve building an entire PCDM object in Fedora and then calling the extension and retrieving the entire graph. The pcdm extension should also be added to the AcrepoServicesIT test.acoburnacoburnhttps://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/14Broadcast Extension Test fails with extra messages2017-09-24T06:33:33-04:00bseegerBroadcast Extension Test fails with extra messagesOne of the broadcast extension integration tests fails with extra messages on each of the queues. It seems that there are probably JMS messages on the queue from other tests.
A @Before function could be created to clear the queue befor...One of the broadcast extension integration tests fails with extra messages on each of the queues. It seems that there are probably JMS messages on the queue from other tests.
A @Before function could be created to clear the queue before hand. bseegerbseegerhttps://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/15Create a WebAC "enhancement" extension2017-09-24T06:33:33-04:00acoburnCreate a WebAC "enhancement" extensionThis extension would enhance the graph of a single Fedora resource by adding triples corresponding to the linked and dereferenced WebAC resource. The extension would read the corresponding `Link` header, identifying the effective ACL, ad...This extension would enhance the graph of a single Fedora resource by adding triples corresponding to the linked and dereferenced WebAC resource. The extension would read the corresponding `Link` header, identifying the effective ACL, adding a `acl:accessControl` triple, if one don't already exist.
https://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/16Review JNDI-based naming conventions for services2017-09-24T06:33:33-04:00acoburnReview JNDI-based naming conventions for servicesWe currently have a number of names for the `osgi.jndi.service.name` values: acrepobroker, inference, jsonld, etc. It would be good to come up with some naming conventions -- maybe there are patterns for this? Should the names include `e...We currently have a number of names for the `osgi.jndi.service.name` values: acrepobroker, inference, jsonld, etc. It would be good to come up with some naming conventions -- maybe there are patterns for this? Should the names include `edu.amherst.acdc` or `acrepo`?
This applies to all of the `acrepo-services-*` modules, which then are used by many of the `acrepo-exts-*` and `acrepo-connector-*` modules.acoburnacoburnhttps://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/17Figure out if we're using PCDM2017-09-24T06:33:33-04:00acoburnFigure out if we're using PCDMThe direction of PCDM 2.0 seems to introduce unnecessary complexity. We should consider simply using the ORE vocabulary. If we do that, we would use the `ore:aggregates` property along with structural typing. A full structure might look ...The direction of PCDM 2.0 seems to introduce unnecessary complexity. We should consider simply using the ORE vocabulary. If we do that, we would use the `ore:aggregates` property along with structural typing. A full structure might look like this:
```
# Top-level resource map
</resources/1> a ore:ResourceMap ;
skos:prefLabel "smth"@en ;
dcterms:description "lots of descriptive metadata here" ;
dcterms:isPartOf </collections/someCollection> ;
ore:describes </resources/resource1/aggregation> .
# Aggregation
</resources/1/aggregation> a ore:Aggregation ;
ldp:contains </resources/1/aggregation/members> ;
iana:first </resources/1/aggregation/members/page1> ;
iana:last </resources/1/aggregation/members/page3> ;
ore:aggregates </resources/1/aggregation/members/page1> , </resources/1/aggregation/members/page2> , </resources/1/aggregation/members/page3> .
# Pages LDP container
</resources/1/aggregation/members> a ldp:DirectContainer ;
ldp:membershipResource </resources/1/aggregation> ;
ldp:hasMemberRelation ore:aggregates ;
ldp:contains </resources/1/aggregation/members/page1> , </resources/1/aggregation/members/page2> , </resources/1/aggregation/members/page3> .
# Individual Pages
</resources/1/aggregation/members/page1> a ore:Aggregation ;
iana:next </resources/1/aggregation/members/page2> ;
ore:aggregates </resources/1/aggregation/members/page1/members/file1> , </resources/1/aggregation/members/page1/members/file2> ;
ldp:contains </resources/1/aggregation/members/page1/members> , </resources/1/aggregation/members/page1/related> .
</resources/1/aggregation/members/page2> a ore:Aggregation ;
iana:prev </resources/1/aggregation/members/page1> ;
iana:next </resources/1/aggregation/members/page3> ;
ore:aggregates </resources/1/aggregation/members/page2/members/file1> , </resources/1/aggregation/members/page2/members/file2> ;
ldp:contains </resources/1/aggregation/members/page2/members> , </resources/1/aggregation/members/page2/related> .
</resources/1/aggregation/members/page3> a ore:Aggregation ;
iana:prev </resources/1/aggregation/members/page2> ;
ore:aggregates </resources/1/aggregation/members/page3/members/file1> , </resources/1/aggregation/members/page3/members/file2> ;
ldp:contains </resources/1/aggregation/members/page3/members> , </resources/1/aggregation/members/page3/related> .
# Files would follow a structure similar to the above structure (FITS metadata goes into a ./related container and uses iana:describedby)....
</resources/1/aggregation/members/page1/members/file1> a fedora:Binary ;
iana:describedby </resources/1/aggregation/members/page1/related/metadata1> .
</resources/1/aggregation/members/page1/members/file2> a fedora:Binary ;
iana:describedby </resources/1/aggregation/members/page1/related/metadata2> .
```https://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/18Familiarize ourselves with HydraCG2018-09-29T13:24:40-04:00acoburnFamiliarize ourselves with HydraCGHydraCG is a vocabulary/spec for describing Web APIs. We should be familiar with it.
http://www.hydra-cg.com/spec/latest/core/
An alternative is Swagger.io: http://swagger.io/HydraCG is a vocabulary/spec for describing Web APIs. We should be familiar with it.
http://www.hydra-cg.com/spec/latest/core/
An alternative is Swagger.io: http://swagger.io/https://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/19Familiarize ourselves with ORE specs2017-09-24T06:33:33-04:00acoburnFamiliarize ourselves with ORE specsThere are a number of ORE documents that we should be familiar with, including:
* http://www.openarchives.org/ore/1.0/http
* http://www.openarchives.org/ore/1.0/datamodel
* http://www.openarchives.org/ore/1.0/discoveryThere are a number of ORE documents that we should be familiar with, including:
* http://www.openarchives.org/ore/1.0/http
* http://www.openarchives.org/ore/1.0/datamodel
* http://www.openarchives.org/ore/1.0/discoveryhttps://gitlab.amherst.edu/acdc/repository-extension-services/-/issues/20Familiarize ourselves with the IIIF specification2017-09-24T06:33:30-04:00acoburnFamiliarize ourselves with the IIIF specificationWe should be more familiar with the IIIF specs, including:
* http://iiif.io/api/presentation/2.1/
* http://iiif.io/api/image/2.1/We should be more familiar with the IIIF specs, including:
* http://iiif.io/api/presentation/2.1/
* http://iiif.io/api/image/2.1/