Closed vsoch closed 9 years ago
isn't this an issue for nidm-query? but yes, I agree that we can omit the unique id from the file itself
actually, I think of the URL where the raw file is stored as the unique id: https://raw.githubusercontent.com/incf-nidash/nidm-query/master/results/23ee1631-51a3-43c9-bd71-b02134d7e36a.json
Yes, I think I was sort of just leaving myself love notes to look at for later. And check this out... we have API!
[image: Inline image 1]
On Sun, Oct 25, 2015 at 12:58 PM, Nolan Nichols notifications@github.com wrote:
isn't this an issue for nidm-query? but yes, I agree that we can omit the unique id from the file itself
— Reply to this email directly or view it on GitHub https://github.com/incf-nidash/nidm-api/issues/6#issuecomment-150963784.
Vanessa Villamia Sochat Stanford University (603) 321-0676
I don't think we should have any hard coded paths to github, that can get messy if we change anything about the repo structure. The paths to the queries are generated dynamically when the application starts and grabs the updated repo - anything that passes our validation is a query. Right now the uid is being stored in the file and as the filename, and what I will do right now is remove the variable from the data structure and generate it dynamically for the user when he/she starts up the API.
What you see above is the parsed queries, all that are available, which is the base address of the API. I'll have more functionality and documentation likely by end of day, going to go back to coding.
oh and the address of the file is a great idea for the URI! I was just saying that we don't need to hard code it into the data structure.
This is pretty cool and yup, that sounds good to not include the RL in the structure. For the query, instead of the github URL we could user the niiri service or purl to handle 303 redirects. For example, https://raw.githubusercontent.com/incf-nidash/nidm-query/master/results/23ee1631-51a3-43c9-bd71-b02134d7e36a.json could just be something like http://purl.org/nidash/iri/23ee1631-51a3-43c9-bd71-b02134d7e36a.json
Is it even worth storing the uid in the file itself? We can just extract the unique ID from the file, and then save the redundancy (and possibility for getting it wrong). Thoughts?