When I update to rely on the latest hydra-works instead of relying on commit 4164209 (see Gemfile.extra), the tests for derivative creation break.
For example:
it 'lacks a thumbnail' do
expect(@generic_file.thumbnail).not_to have_content
end
| <http://127.0.0.1:8983/fedora/rest/dev/df/93/78/f3/df9378f3-480a-4ad8-8ee7-7c3a100ac263> <http://www.iana.org/assignments/link-relations/first> <http://127.0.0.1:8983/fedora/rest/dev/df/93/78/f3/df9378f3-480a-4ad8-8ee7-7c3a100ac263/related_objects/c0a7d413-47a2-4ebf-aa14-3384e8af86bd>; | |
| <http://www.iana.org/assignments/link-relations/last> <http://127.0.0.1:8983/fedora/rest/dev/df/93/78/f3/df9378f3-480a-4ad8-8ee7-7c3a100ac263/related_objects/c0a7d413-47a2-4ebf-aa14-3384e8af86bd> . | |
| <http://127.0.0.1:8983/fedora/rest/dev/df/93/78/f3/df9378f3-480a-4ad8-8ee7-7c3a100ac263/related_objects/c0a7d413-47a2-4ebf-aa14-3384e8af86bd/fcr:export?format=jcr/xml> <http://purl.org/dc/elements/1.1/format> <http://fedora.info/definitions/v4/repository#jcr/xml> . | |
| <http://fedora.info/definitions/v4/repository#jcr/xml> <http://www.w3.org/2000/01/rdf-schema#label> "jcr/xml" . | |
| <http://127.0.0.1:8983/fedora/rest/dev/df/93/78/f3/df9378f3-480a-4ad8-8ee7-7c3a100ac263/related_objects/c0a7d413-47a2-4ebf-aa14-3384e8af86bd> a <http://www |
| container_predicate = ::RDF::URI.new("http://example.com/hasFiles") | |
| options = {type: ::RDF::URI.new("http://example.com/primaryFile") } | |
| # This works but is inefficient | |
| contained_uris = query_node.resource.query(predicate: container_predicate).map { |r| r.object.to_s } | |
| contained_objects = contained_uris.map { |object_uri| klass.find(klass.uri_to_id(object_uri)) } | |
| filtered_objects = contained_objects.select {|o| o.metadata_node.type.include?(options[:type]) } | |
| return filtered_objects.first | |
| # Tried this, but it doesn't work |
| module ActiveFedora | |
| module Associations | |
| class DirectlyContainsOneAssociation < SingularAssociation #:nodoc: | |
| # Finds objects contained by the container predicate (either the configured has_member_relation or ldp:contains) | |
| # TODO: Refactor this to use solr. Requires indexing ActiveFedora::File objects into solr, including their RDF.type and, if possible, the id of their container | |
| def find_target | |
| query_node = if container_predicate = options[:has_member_relation] | |
| owner | |
| else |
| Verifying that +flyingzumwalt is my blockchain ID. https://onename.com/flyingzumwalt |
----- September 23rd, 2016 -----
btrask [6:29 PM]
@edsilv response to your question, "what is the business case for decentralization?" https://bentrask.com/?q=hash://sha256/33ba37008b55d3188c6b1bf8
edsilv [5:28 AM]
@btrask interesting stuff about devops applications. I think online libraries/archives too are a natural place for decentralised tech to take root. @flyingzumwalt mentioned that David Dias is presenting at the IIPC general assembly next spring. Would be great if he was armed with a solid set of business cases for the "decision makers" in the crowd.
"As a public service institution I want to provide a scalable, highly available, and free as in freedom and beer collection of knowledge" type thing.
IPLD-based Version History
This is just a sketch of a possibility. If we just want a git-style toolchain with git version graph, it might be better to just put an ipfs storage adapter behind go-git -- basically putting IPFS unixfs trees where git usually creates git tree objects. In that case you would have regular git commit objects, not IPLD objects. That would be less reusable beyond the git context but it would fit better with existing git-based tooling.
Keep in mind: it will be really useful to be able to use IPFS files api to manipulate these trees, allowing you to do things like modify part of a large dataset and commit the changes without ever pulling the whole dataset -- you can just pull the parts that you're changing.
I hereby claim:
To claim this, I am signing this object: