| # Same 6021 Triples | |
| # JSON-LD (I don't have a TTL parser...) | |
| iex(34)> Benchwarmer.benchmark(fn -> Client.get(%ExFedora.Client{url: "http://localhost:8984/rest"}, "4e/38/da/ba/4e38daba-a6b9-4ffb-a138-52041782f2cb") end) | |
| *** #Function<20.54118792/0 in :erl_eval.expr/5> *** | |
| 4.3 sec 1 iterations 4351705.0 μs/op | |
| [%Benchwarmer.Results{args: [], duration: 4351705, | |
| function: #Function<20.54118792/0 in :erl_eval.expr/5>, n: 1, prev_n: 1}] | |
| # 4.3 seconds |
Smoothies cannot be edited @anarchivist -- 6:52 PM PDT - 23 Apr 2015
The key question I'm setting out to answer is: How can we account for routine change and updates in our metadata records. An initial attempt to derive a model for change from current practice has led to some corollary questions about the relationship between Records, Documents, Description Sets, Application Profiles, Resources, and RDF Sourceslit review:
| # Note: this is all pseudocode to mock up a DSL at this point. | |
| # THIS IS A VERY INCOMPLETE EXAMPLE; much work to do for mods. | |
| bpl_mods_mapper = Krikri::Mapper.new | |
| bpl_mods_mapper.build do | |
| input_format :xml # :json, :csv, :tsv others? | |
| selector type: :xpath, "//record" | |
| # select an XPath relative to `selector` as the default parent for mappings |
| # RdfResource is a subclass of RDF::Graph with property configuration, accessors, and some other methods | |
| # for managing "resources" as discrete subgraphs which can be managed by a Hydra datastream model. | |
| # | |
| # The relevant modules and class are: | |
| # | |
| # https://github.com/OregonDigital/oregondigital/tree/master/lib/oregon_digital/rdf/rdf_configurable.rb | |
| # https://github.com/OregonDigital/oregondigital/tree/master/lib/oregon_digital/rdf/rdf_properties.rb | |
| # https://github.com/OregonDigital/oregondigital/tree/master/lib/oregon_digital/rdf/rdf_resource.rb | |
| bnode = OregonDigital::RDF::RdfResource.new |
