db-1.0.json

{"milestones":[],"attachments":[{"path":"attachments\/56f46b1c520343a39c7de92748d41f86","issue":5,"user":"hkthorsen","filename":"BobFitch.mods"},{"path":"attachments\/76078bc148ca4116ab375d45b205fef4","issue":1,"user":"hkthorsen","filename":"Photograph_VideoArcardes.xml"}],"versions":[],"comments":[{"content":"Addressed by latest commit.","created_on":"2015-05-27T14:31:59.587808+00:00","user":"wsalesky","updated_on":null,"issue":11,"id":18403975},{"content":"Addresses issue #11.\n\n\n→ <<cset c7ac535bc778>>","created_on":"2015-05-27T14:31:47.873164+00:00","user":"wsalesky","updated_on":null,"issue":11,"id":18403967},{"content":null,"created_on":"2015-05-26T01:34:11.332121+00:00","user":"wsalesky","updated_on":null,"issue":10,"id":18345985},{"content":"Issue has been resolved in latest commit.","created_on":"2015-05-25T01:58:52.638998+00:00","user":"wsalesky","updated_on":null,"issue":9,"id":18324197},{"content":"Addresses Issue #9. Adds rdf:resource for places with valueURI.\n\n\n→ <<cset 0910f73833a9>>","created_on":"2015-05-25T00:28:04.566840+00:00","user":"wsalesky","updated_on":null,"issue":9,"id":18323616},{"content":"Finally getting back to this. Sorry for the delay. I think we can improve the handling of the place element with valueURI. \n-Winona\n","created_on":"2015-05-22T19:45:58.583658+00:00","user":"wsalesky","updated_on":null,"issue":9,"id":18302750},{"content":"Oh, meant to say, I am going to try using VIAF as well, just to compare. \n","created_on":"2015-05-22T19:44:48.646961+00:00","user":"wsalesky","updated_on":null,"issue":8,"id":18302736},{"content":"Yes I did get a result... all I need was the uri, which I grab from the head, but it took far to long. Will try again now that I am home, but do not expect much performance gain. FYI The same query form xquery, using doc() returns quite quickly (tested in eXide). ","created_on":"2015-05-22T19:44:17.162637+00:00","user":"wsalesky","updated_on":null,"issue":8,"id":18302731},{"content":"I was querying the VIAF names files (\"query=local.names+all+ ...\"). Did you actually get a result from running a lookup? One problem seems to be the 303 redirect from the id.loc.gov label service. XSLT fn:document seems to work okay when you are looking up a static XML file online, but can't seem to do anything fancier than that.\n\nI just did a quick test:\n\nXML\n\n    <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n    <name>\n        <namePart>Mentelin, Johann, approximately 1410-1478<\/namePart>\n    <\/name>\n\nXSLT\n\n    <?xml version=\"1.0\" encoding=\"UTF-8\"?>\n    <xsl:stylesheet xmlns:xsl=\"http:\/\/www.w3.org\/1999\/XSL\/Transform\" version=\"2.0\">\t\n        <xsl:strip-space elements=\"*\"\/>\t\n        <xsl:template match=\"namePart\">\n            <xsl:value-of select=\"document(concat('http:\/\/id.loc.gov\/authorities\/label\/', encode-for-uri(.)))\"\/>\t\t\n        <\/xsl:template>\t\t\n    <\/xsl:stylesheet>\n\nResult (after about 10 minutes) [snipped]\n\n    Mentelin, Johann, approximately 1410-1478 - LC Linked Data Service (Library of Congress)\n\n    var uri = \"\/authorities\/names\/nr96010181\";\n\n    var graphgear_data = {\n        xml:uri + \".gg.xml\",\n        header:''\n    };\n\n    \/\/ var uri = \"\/authorities\/names\/nr96010181\";\n\n    \/\/ $(function() {\n    \/\/    $(\"#loctoggler\").accordion( { autoHeight: false } );\n    \/\/ });\n\nNot what I was expecting!\n","created_on":"2015-05-22T19:18:36.936014+00:00","user":"timathom","updated_on":null,"issue":8,"id":18302413},{"content":"Using Saxon PE. Maybe it is the crappy coffee shop wifi, but I suspect not. What VIAF API were you using? ","created_on":"2015-05-22T18:35:04.660872+00:00","user":"wsalesky","updated_on":null,"issue":8,"id":18301821},{"content":"Yes, but it has been a while, so maybe things are better in my memory. I was using it to resolve names against VIAF. Are you using Saxon-HE?","created_on":"2015-05-22T18:19:39.715436+00:00","user":"timathom","updated_on":null,"issue":8,"id":18301534},{"content":"I'm finding it to be incredibly slow. Did you use this with xslt?","created_on":"2015-05-22T18:04:11.105043+00:00","user":"wsalesky","updated_on":null,"issue":8,"id":18301308},{"content":"I had considered it. Perhaps time to revisit, I would much prefer to use expath http client, but we can't expect users to install the necessary dependancies. ","created_on":"2015-05-15T18:09:37.677492+00:00","user":"wsalesky","updated_on":null,"issue":8,"id":18134602},{"content":"Resloved","created_on":"2015-05-26T00:43:28.797883+00:00","user":"wsalesky","updated_on":null,"issue":7,"id":18344841},{"content":"Ah, no it should not do that to the authorizedAccessPoint. Thanks for catching that. \nPlease do continue to be really picky, I prefer to catch all the little things up front before the code is released. \n-Winona\n","created_on":"2015-05-15T20:13:38.363403+00:00","user":"wsalesky","updated_on":null,"issue":7,"id":18136568},{"content":"Seems to work fine now. I also added some dates and middle initials to complicate things and it came out fine -- except that it adds a period to every string in label and authorizedAccessPoint. Is that intentional -- sorry, I am being really picky here, I know.","created_on":"2015-05-15T20:08:50.210250+00:00","user":"mwacker","updated_on":null,"issue":7,"id":18136520},{"content":"Yes there should. Latest commit will handle this. \n\nLatest commit:\nUpdated mods:name to add punctuation into bf:Person > bf:label.\nCode checks for existing punctuation only adds if no punctuation is present.\nMay cause issues with middle initials and dates.","created_on":"2015-05-15T13:31:50.619386+00:00","user":"wsalesky","updated_on":null,"issue":7,"id":18128621},{"content":"Thanks Hilary. I think we will follow the xquery examples for now, and then after we get some more feed back we can re-evaluate. I appreciate all your input and testing help!\n-Winona\n","created_on":"2015-05-05T14:22:50.749996+00:00","user":"wsalesky","updated_on":null,"issue":6,"id":17887282},{"content":"Sorry to take so long to respond, Winona. I had a conference last week and it ended up consuming a ton of time. We have all been confused by the various title properties here and what gets used when, but I think to follow the xquery model then mods:title with no titleInfo would map to bf:workTitle. My understanding on the MARC side is that when there is no 240 or 130 in the record, the 245 is considered the work title, so I would assume that this same reasoning would apply for MODS.\nThanks! Hilary","created_on":"2015-04-29T21:52:31.803013+00:00","user":"hkthorsen","updated_on":null,"issue":6,"id":17781001},{"content":"Resolved","created_on":"2015-05-27T14:42:00.192307+00:00","user":"wsalesky","updated_on":"2015-05-27T14:42:37.356939+00:00","issue":5,"id":18404300},{"content":"No problem, thanks for the debugging help. I think the first draft is going public soon. \n-Winona\n","created_on":"2015-04-17T14:23:35.103410+00:00","user":"wsalesky","updated_on":null,"issue":5,"id":17461577},{"content":"Thanks for the fix!","created_on":"2015-04-16T22:38:39.691778+00:00","user":"hkthorsen","updated_on":null,"issue":5,"id":17444964},{"content":"@hkthorsen I fixed it so it will run, there remain some questions about how to handle identifiers, hopefully these can get ironed out in round 2. \n","created_on":"2015-04-16T18:12:14.276201+00:00","user":"wsalesky","updated_on":null,"issue":5,"id":17440035},{"content":"I will take a look and make sure the solution address both use cases (this one and the one Tim brought up).  Thanks!\n","created_on":"2015-04-11T01:34:45.865035+00:00","user":"wsalesky","updated_on":null,"issue":5,"id":17312535},{"content":"@mwacker - currently the code only resolves when roleTerm@type='code' the example file has all roleTerm@type='text'. \nI use the http:\/\/id.loc.gov\/vocabulary\/relators.madsrdf.rdf to resolve the codes, however, as you can see there are no matching text values. I clicked through some of the available files and none of them include text values, so this may be the best we can do currently. \n\nWe can leave the issue open for further investigation. \n-Winona","created_on":"2015-05-15T13:43:39.101809+00:00","user":"wsalesky","updated_on":null,"issue":4,"id":18128960},{"content":"FYI: Just uploaded the CUL_IR_Example file. Contains examples of roles that are currently not being transformed.","created_on":"2015-05-14T19:22:00.536612+00:00","user":"mwacker","updated_on":null,"issue":4,"id":18112922},{"content":"Addresses Issue #4\nTests roleTerm type='code' against MARC Code List for Relators.\n\n\n→ <<cset f9c9d59bd9ec>>","created_on":"2015-04-07T03:10:34.760391+00:00","user":"wsalesky","updated_on":"2015-04-07T03:11:28.209938+00:00","issue":4,"id":17203487},{"content":"Resolved. See issue #10 for related issue on valueURI","created_on":"2015-05-27T14:43:25.794617+00:00","user":"wsalesky","updated_on":null,"issue":3,"id":18404346},{"content":"Addresses Issue #3.\n\n\n→ <<cset 176f2d0e5c0c>>","created_on":"2015-04-07T01:15:26.995195+00:00","user":"wsalesky","updated_on":null,"issue":3,"id":17202213},{"content":"Duplicate of #1","created_on":"2015-05-27T14:43:58.085787+00:00","user":"wsalesky","updated_on":null,"issue":2,"id":18404358},{"content":"EDTF is expressed in rdf at id:\nhttp:\/\/id.loc.gov\/datatypes\/edtf\nIs that what you needed?  \n","created_on":"2015-05-15T19:53:01.084912+00:00","user":"ntra00","updated_on":null,"issue":1,"id":18136340},{"content":"Thanks @timathom. That is interesting. Maybe @tmeehleib or @ntra00 can weigh in on this issue? \n","created_on":"2015-05-15T17:58:41.358078+00:00","user":"wsalesky","updated_on":null,"issue":1,"id":18134384},{"content":"LC's Extended Date\/Time Format (EDTF) allows for encoding date intervals: http:\/\/www.loc.gov\/standards\/datetime\/pre-submission.html#interval. Not an official standard yet, but it's being used widely by catalogers. Would be nice to be able to use it as an @rdf:datatype attribute, but I don't think there are canonical URIs (e.g., like \"http:\/\/www.w3.org\/2001\/XMLSchema#gYear\").","created_on":"2015-05-15T17:52:00.885233+00:00","user":"timathom","updated_on":null,"issue":1,"id":18134286},{"content":"Thanks for the sample files. ","created_on":"2015-05-15T13:48:42.132006+00:00","user":"wsalesky","updated_on":null,"issue":1,"id":18129090},{"content":"Done.","created_on":"2015-05-14T18:38:29.295646+00:00","user":"mwacker","updated_on":null,"issue":1,"id":18112158},{"content":"Agreed!","created_on":"2015-05-14T18:33:36.128982+00:00","user":"mwacker","updated_on":null,"issue":1,"id":18112081},{"content":"@mwacker would you mind adding your xml to repo so I can test it as well?  I think I gave you write permissions. \n","created_on":"2015-05-14T18:33:29.055597+00:00","user":"wsalesky","updated_on":null,"issue":1,"id":18112080},{"content":"I had discussed this with @hkthorsen earlier and we were both unsure which way to go. \n\nI think since there is no start\/end in BIBFRAME it may be better to use the hyphen, to make it clear it is a date range, otherwise they simply appear to be two separate dates. ","created_on":"2015-05-14T18:32:41.490558+00:00","user":"wsalesky","updated_on":null,"issue":1,"id":18112066},{"content":"Thanks! So now from \n<mods:originInfo>\n    <mods:dateCreated>between 1879 and 1950<\/mods:dateCreated>\n    <mods:dateCreated encoding=\"w3cdtf\" keyDate=\"yes\" point=\"start\" qualifier=\"inferred\">1879<\/mods:dateCreated>\n    <mods:dateCreated encoding=\"w3cdtf\" point=\"end\">1950<\/mods:dateCreated>\n  <\/mods:originInfo>\n\nwe get\n\n<bf:publication>\n         <bf:Provider>\n            <bf:providerDate>between 1879 and 1950<\/bf:providerDate>\n            <bf:providerDate>1879<\/bf:providerDate>\n            <bf:providerDate>1950<\/bf:providerDate>\n         <\/bf:Provider>\n      <\/bf:publication>\n\nDo you think it is better to have the start and end date in two separate bf:providerDate elements or combine them with a hyphen since we can't say in BIBFRAME which one is a start and which one is the end date in separate properties. I am undecided -- what do you think?","created_on":"2015-05-14T18:28:29.594410+00:00","user":"mwacker","updated_on":null,"issue":1,"id":18111994},{"content":"Updated xslt to add bf:publication for originInfo without @eventType.  ","created_on":"2015-05-14T15:19:37.639059+00:00","user":"wsalesky","updated_on":null,"issue":1,"id":18108012},{"content":"@mwacker We can do that. I will take a look at the code today. ","created_on":"2015-05-14T14:04:19.206468+00:00","user":"wsalesky","updated_on":null,"issue":1,"id":18105373},{"content":"I just ran into this issue when converting one of my test records. @eventType has been introduced relatively late in MODS, so there will be many, many records without @eventType. So I have a MODS record with originInfo (no event type) and a dateCreated (no place, no publisher). This gets translated into bf:providerStatement, not into providerDate specifically. Could this create issues when trying to query the data for specific dates? I'd prefer it to be mapped into the more specific providerDate.","created_on":"2015-05-13T18:31:13.528385+00:00","user":"mwacker","updated_on":null,"issue":1,"id":18086380},{"content":"Addresses Issue #1. Concats dates in bf:providerStatement as ranges. Added dateCreated to bf:providerStatement.\nOnly uses bf:providerStatement if no @eventType is present.\n\nStill need to address date ranges in bf:providerDate (to use as two dates or a single string).\n\n\n→ <<cset e895e1ca4fd2>>","created_on":"2015-04-06T12:35:28.830911+00:00","user":"wsalesky","updated_on":null,"issue":1,"id":17184222},{"content":"There is no indication in the mapping on date ranges. I think I will leave it for now, but put it on a list of questions. \n\nYou are correct about originInfo, it should only be used if there is not @evenType.\n","created_on":"2015-04-06T02:56:54.469881+00:00","user":"wsalesky","updated_on":null,"issue":1,"id":17176240}],"meta":{"default_milestone":null,"default_assignee":null,"default_kind":"bug","default_component":null,"default_version":null},"components":[],"issues":[{"status":"resolved","priority":"minor","kind":"bug","content_updated_on":null,"voters":[],"title":"Mismatch in mods:subject\/mods:name","reporter":"wsalesky","component":null,"watchers":["wsalesky"],"content":"See avery.novelties.ltv for an example. ","assignee":"wsalesky","created_on":"2015-05-26T01:54:09.541500+00:00","version":null,"edited_on":null,"milestone":null,"updated_on":"2015-05-27T14:31:59.569569+00:00","id":11},{"status":"new","priority":"major","kind":"bug","content_updated_on":"2015-05-26T01:34:11.319492+00:00","voters":[],"title":"valueURI","reporter":"wsalesky","component":null,"watchers":["wsalesky"],"content":"Review other elements with valueURI, which may have been overlooked in first round. \r\n\r\nelements:\r\n* titleInfo\r\n* name\r\n* roleTerm\r\n* genre\r\n* placeTerm\r\n* originInfo\/frequency \r\n* language\/languageTerm\r\n* language\/scriptTerm\r\n* physicalDescription\/form\r\n* targetAudience\r\n* subject\/child::*\r\n* classification\r\n* location\/physicalLocation\r\n* location\/holdingSimple\/copyInformation\/form\r\n* recordInfo\/recordContentSource\r\n* recordInfo\/langugeOfCataloging\/languageTerm, scriptTerm\r\n* recordInfo\/langugeOfCataloging\/descriptionStandard\r\n* ","assignee":"wsalesky","created_on":"2015-05-25T02:04:59.217556+00:00","version":null,"edited_on":null,"milestone":null,"updated_on":"2015-05-26T01:34:11.318130+00:00","id":10},{"status":"resolved","priority":"major","kind":"bug","content_updated_on":null,"voters":[],"title":"placeTerm with valueURI","reporter":"mwacker","component":null,"watchers":["wsalesky"],"content":"I just tested an example using valueURI in addtion to the string. See avery.novelties.ltv example. It looks like the valueURI is getting lost. I freely admit that the MODS\/BIBRAME mapping was a bit strange there, too. Just looked at it again. Anyway, should it be something like this (created with the BIBFRAME editor)?\r\n\r\nID: http:\/\/example.org\/99ded35c-2a83-6629-4313-980ec3c6d0c4\r\n\tType(s)\r\n\t\tundefined\r\n\tbf:publication\r\n\t\thttp:\/\/example.org\/999212e8-4f95-6623-3d6c-408b51a0df4c\r\n\r\n\r\nID: http:\/\/example.org\/9867226d-47e0-f15d-c3bb-f4b5f97aa675\r\n\tType(s)\r\n\t\tundefined\r\n\tbf:hasAuthority\r\n\t\thttp:\/\/id.loc.gov\/authorities\/names\/n79005665\r\n\tbf:authorizedAccessPoint\r\n\t\tLondon (England)\r\n\tbf:authoritySource\r\n\t\thttp:\/\/id.loc.gov\/authorities\/names\r\n\r\n\r\nID: http:\/\/example.org\/999212e8-4f95-6623-3d6c-408b51a0df4c\r\n\tType(s)\r\n\t\tundefined\r\n\tbf:providerPlace\r\n\t\thttp:\/\/example.org\/9867226d-47e0-f15d-c3bb-f4b5f97aa675","assignee":null,"created_on":"2015-05-15T20:46:57.640955+00:00","version":null,"edited_on":null,"milestone":null,"updated_on":"2015-05-25T01:58:52.621379+00:00","id":9},{"status":"new","priority":"major","kind":"enhancement","content_updated_on":null,"voters":[],"title":"Authorities lookup","reporter":"timathom","component":null,"watchers":["wsalesky"],"content":"@wsalesky What about using the XSLT fn:document() to resolve against http:\/\/id.loc.gov\/authorities\/label\/? Too slow? I've used it for (fairly) large files, and performance didn't seem terrible.","assignee":"wsalesky","created_on":"2015-05-15T18:05:11.520032+00:00","version":null,"edited_on":null,"milestone":null,"updated_on":"2015-05-22T19:44:48.651422+00:00","id":8},{"status":"resolved","priority":"minor","kind":"bug","content_updated_on":null,"voters":[],"title":"nameParts","reporter":"mwacker","component":null,"watchers":["wsalesky"],"content":"We are using name\/namePart@type=\"family\" and name\/namePart@type=\"given\" in our IR. See CUL_IR_Example. The resulting labels and authorized access points in the transformation combine first and last names without a comma, which results in labels reading \"Wacker Melanie\". Should there be a comma?","assignee":"wsalesky","created_on":"2015-05-14T19:41:10.630921+00:00","version":null,"edited_on":null,"milestone":null,"updated_on":"2015-05-26T00:43:28.785697+00:00","id":7},{"status":"new","priority":"major","kind":"bug","content_updated_on":null,"voters":[],"title":"workTitle clarification question","reporter":"wsalesky","component":null,"watchers":["wsalesky"],"content":"In the mapping it looks like only titleInfo@type=\"uniform\" map to bf:workTitle\r\n\r\nHowever, in the xquery it looks 245 maps to bf:workTitles in addition to 240. Thoughts on which way the mods xslt should go?\r\n\r\nThanks!\r\n-Winona\r\n\r\n","assignee":null,"created_on":"2015-04-17T15:37:45.568941+00:00","version":null,"edited_on":null,"milestone":null,"updated_on":"2015-05-05T14:22:50.752316+00:00","id":6},{"status":"resolved","priority":"major","kind":"bug","content_updated_on":null,"voters":[],"title":"Multiple identifiers","reporter":"hkthorsen","component":null,"watchers":["wsalesky"],"content":"We have a lot of records with multiple mods:identifiers, so the transformation of those breaks. Based on a note in the XSLT, I think this issue has already been noted, but thought I'd bring it up as something that will definitely be an issue in many of our records. Example attached.","assignee":null,"created_on":"2015-04-10T19:27:53.898543+00:00","version":null,"edited_on":null,"milestone":null,"updated_on":"2015-05-27T14:42:00.170629+00:00","id":5},{"status":"new","priority":"major","kind":"bug","content_updated_on":null,"voters":[],"title":"roleTerm not being output as relators","reporter":"wsalesky","component":null,"watchers":["wsalesky"],"content":"","assignee":"wsalesky","created_on":"2015-04-07T01:53:56.262138+00:00","version":null,"edited_on":null,"milestone":null,"updated_on":"2015-05-15T13:43:39.104579+00:00","id":4},{"status":"resolved","priority":"major","kind":"bug","content_updated_on":null,"voters":[],"title":"mods:name@valueURI not converting correctly","reporter":"wsalesky","component":null,"watchers":["wsalesky"],"content":"Test case: \r\nbmtnaau.xml links to VIAF records. \r\n","assignee":"wsalesky","created_on":"2015-04-07T01:05:11.432546+00:00","version":null,"edited_on":null,"milestone":null,"updated_on":"2015-05-27T14:43:25.763693+00:00","id":3},{"status":"resolved","priority":"major","kind":"enhancement","content_updated_on":null,"voters":[],"title":"Date ranges in bf:providerDates","reporter":"wsalesky","component":null,"watchers":["tmeehleib","wsalesky"],"content":"Unclear mapping on date ranges in bf:providerDates, should ranges be encoded as a single string: startDate-endDate ? Or as two different bf:providerDates?\r\n","assignee":"tmeehleib","created_on":"2015-04-06T12:38:18.095452+00:00","version":null,"edited_on":null,"milestone":null,"updated_on":"2015-05-27T14:43:58.068253+00:00","id":2},{"status":"new","priority":"minor","kind":"enhancement","content_updated_on":null,"voters":[],"title":"dateCreated with a date range + bf:providerStatement","reporter":"hkthorsen","component":null,"watchers":["ntra00","wsalesky"],"content":" <dateCreated encoding=\"w3cdtf\" keyDate=\"yes\" point=\"start\"> and  <dateCreated encoding=\"w3cdtf\" point=\"end\"> don't have a mapping, so they are ending up as individual bf:providerDates instead of a range. It is not clear from the Bibframe vocabulary whether or not bf:providerDate can have a date range, so maybe that's why there isn't a mapping. \r\n\r\nI also am a bit confused by the mapping of originInfo to bf:providerStatement--should bf:providerStatement only be used if there is no @eventType?","assignee":null,"created_on":"2015-04-02T21:42:56.237095+00:00","version":null,"edited_on":null,"milestone":null,"updated_on":"2015-05-15T19:53:01.103630+00:00","id":1}],"logs":[{"comment":18345985,"changed_to":"Review other elements with valueURI, which may have been overlooked in first round. \r\n\r\nelements:\r\n* titleInfo\r\n* name\r\n* roleTerm\r\n* genre\r\n* placeTerm\r\n* originInfo\/frequency \r\n* language\/languageTerm\r\n* language\/scriptTerm\r\n* physicalDescription\/form\r","field":"content","created_on":"2015-05-26T01:34:11.337128+00:00","user":"wsalesky","issue":10,"changed_from":"Review other elements with valueURI, which may have been overlooked in first round. \r\n\r\nelements:\r\ntitleInfo\r\nname\r\nroleTerm\r\ngenre\r\nplaceTerm\r\noriginInfo\/frequency \r\nlanguage\/languageTerm\r\nlanguage\/scriptTerm\r\nphysicalDescription\/form\r\ntargetAudience\r\ns"},{"comment":18404358,"changed_to":"resolved","field":"status","created_on":"2015-05-27T14:43:58.089458+00:00","user":"wsalesky","issue":2,"changed_from":"new"},{"comment":18404300,"changed_to":"resolved","field":"status","created_on":"2015-05-27T14:42:00.201341+00:00","user":"wsalesky","issue":5,"changed_from":"new"},{"comment":18403975,"changed_to":"resolved","field":"status","created_on":"2015-05-27T14:31:59.595805+00:00","user":"wsalesky","issue":11,"changed_from":"new"},{"comment":18344841,"changed_to":"resolved","field":"status","created_on":"2015-05-26T00:43:28.801637+00:00","user":"wsalesky","issue":7,"changed_from":"new"},{"comment":18404346,"changed_to":"resolved","field":"status","created_on":"2015-05-27T14:43:25.803748+00:00","user":"wsalesky","issue":3,"changed_from":"new"},{"comment":18324197,"changed_to":"resolved","field":"status","created_on":"2015-05-25T01:58:52.646689+00:00","user":"wsalesky","issue":9,"changed_from":"new"}]}