Fwd: Decision on your PeerJ submission: "Achieving human and machine accessibility of cited data in scholarly publications" (#2014:12:3509:1:1:REVIEW)
Tim Clark
Begin forwarded message:From: PeerJ <peer....@peerj.com>Subject: Decision on your PeerJ submission: "Achieving human and machine accessibility of cited data in scholarly publications" (#2014:12:3509:1:1:REVIEW)Reply-To: PeerJ <peer....@peerj.com>To: Tim Clark <tim_...@harvard.edu>Date: February 1, 2015 at 1:42:13 PM EST
PeerJ Thank you for your submission to PeerJ. I am writing to inform you that in my opinion as the Academic Editor for your article, your manuscript "Achieving human and machine accessibility of cited data in scholarly publications" (#2014:12:3509:1:1:REVIEW) requires some minor revisions before we could accept it for publication.
The comments supplied by the reviewers on this revision are pasted below. My comments are as follows:
Editor's comments
This revision nicely addresses the issues raised in the first round of reviews, resulting in a much clearer and more thorough paper.
I have a few small content comments that should be addressed in the final submission, and one question that I would like to raise:
1. At the end of the paragraph starting with "The publishing workflow...", you have a sentence with nested open parens and only one close paren.
2. The last sentence on page 5, describing REST applications, ends without a period. Furthermore, the final claim seems a bit funny - REST is not particularly tied to mobile apps.
3. The first paragraph on page 11 mentions an ORE resource map, without any citation or description of what that might refer to.
I am assuming these issues can be addressed quickly and should require no further review.
My question regards web-linking. I am not familiar with this proposal, but it seems very ad-hoc. Are there any alternative approaches that provide for potentially more useful metadata, perhaps through RDF-a? I would not suggest revising the manuscript to raise this question, but I am curious...If you are willing to undertake these changes, please submit your revised manuscript (with any rebuttal information*) to the journal within 45 days.
* Resubmission checklist:
When resubmitting, in addition to any revised files (e.g. a clean manuscript version, figures, tables, which you will add to the "Primary Files" upload section), please also provide the following two items:
- A rebuttal Letter: A single document where you address all the Editor and reviewers' suggestions or requirements, point-by-point.
- A 'Tracked Changes' version of your manuscript: A document that shows the tracking of the revisions made to the manuscript. You can also choose to simply highlight or mark in bold the changes if you prefer.
Accepted formats for the rebuttal letter and tracked changes document are: docx (preferred), doc, or PDF.
Harry Hochheiser
Academic Editor for PeerJ
Reviewer Comments
Reviewer 1 (Anonymous)
Basic reporting
No Comments
Experimental design
No Comments
Validity of the findings
No Comments
Comments for the author
The new draft is more thorough, clear, and readable.
© 2014, PeerJ, Inc. PO Box 614 Corte Madera, CA 94976, USA
Joan Starr
Thank you for taking care of this, Tim. I’m not the right person to respond to the side bar, so I’ll leave that to others.
--Joan
To unsubscribe from this group and stop receiving emails from it, send an email to idmeta+un...@force11.org.
Joe Hourcle
On Feb 1, 2015, at 1:45 PM, Tim Clark wrote:
> The PeerJ decision on our article is “accept with minor revisions” - which I will do and submit today.
>
> Would anyone like to craft a response to the editor on his sidebar question regarding web linking? Please send to me and I’ll forward - with attribution.
Also, just before you sent this, I got some comments from John Kunze. I had sent him the .tex to put his notes in, so I'll need to diff the files to extract his comments.
In addition, there were quite a few of us at the 'Software and Data Citation' workshop in Arlington, VA last weekend. (I crashed it; Mercé, Tim, Ruth and Joan were invited). I wasn't there for the first day's morning discussions, but in the afternoon Tim mentioned that it might be worth addressing the issue of citation chaining in the paper. If nothing else, mentioning that machine-actionable landing pages enable resolution of the chain. in other words:
'Author-A' uses 'dataset-1', which lists 'Author-A' as its creator
'dataset-1' as an aggregation of 20 other datasets
We should be able to credit the creators of the other 20 datasets as contributing to this paper.
-Joe
>> Begin forwarded message:
>>
>> From: PeerJ <peer....@peerj.com>
>> Subject: Decision on your PeerJ submission: "Achieving human and machine accessibility of cited data in scholarly publications" (#2014:12:3509:1:1:REVIEW)
>> Reply-To: PeerJ <peer....@peerj.com>
>> To: Tim Clark <tim_...@harvard.edu>
>> Date: February 1, 2015 at 1:42:13 PM EST
>>
>> PeerJ
>> Thank you for your submission to PeerJ. I am writing to inform you that in my opinion as the Academic Editor for your article, your manuscript "Achieving human and machine accessibility of cited data in scholarly publications" (#2014:12:3509:1:1:REVIEW) requires some minor revisions before we could accept it for publication.
>>
>> The comments supplied by the reviewers on this revision are pasted below. My comments are as follows:
>>
>> Editor's comments
>>
>> This revision nicely addresses the issues raised in the first round of reviews, resulting in a much clearer and more thorough paper.
>>
>> I have a few small content comments that should be addressed in the final submission, and one question that I would like to raise:
>>
>> 1. At the end of the paragraph starting with "The publishing workflow...", you have a sentence with nested open parens and only one close paren.
>>
>> 2. The last sentence on page 5, describing REST applications, ends without a period. Furthermore, the final claim seems a bit funny - REST is not particularly tied to mobile apps.
REST allows for the content to be returned in multiple formats. (see \textbf{\emph{Serving the landing pages}} for details). REST also allows multiple data formats such as JSON (JavaScript Object Notation) (\cite {JSON}), and provides better support for mobile applications (e.g., caching, bandwidth, etc.).
I don't know if that's completely true. The 'GET' can be cached for REST (at which point, it's no different than any standard web resource). The other operations can't be.
My reason for agreeing on REST over SOAP is that the focus in REST is on the documents being stored & retrieved. The focus in SOAP is on the service (the object), and the methods/functions (the SOAP Action) that it provides. If you had a search service, or a service that did processing (eg, file conversion), I'd very likely favor SOAP over REST.
The only advantage for mobile is the ability to cache it, and I don't know how much caching mobile browsers actually do. It's likely that that apps that have an 'offline mode' would prefer REST over SOAP, as they can collect up the resources that they need for offline processing, while the nature of SOAP requires an active internet connection.
>> 3. The first paragraph on page 11 mentions an ORE resource map, without any citation or description of what that might refer to.
If the data is available as a relatively small number of files, either as parts of the whole collection, mirrored at multiple locations, or as multiple packaged forms, link to an ORE resource map (\cite{OAI-ORE}) to describe the relationships between the files.
It seems that the reference on page 11 cites "Lagoze:2007" (I assume that was in response to the feedback).
>> I am assuming these issues can be addressed quickly and should require no further review.
>>
>> My question regards web-linking. I am not familiar with this proposal, but it seems very ad-hoc. Are there any alternative approaches that provide for potentially more useful metadata, perhaps through RDF-a? I would not suggest revising the manuscript to raise this question, but I am curious...
You can attach the HTTP headers to any type of content, including RDF files.
If you were using a schema that had this concept of alternate representations of a given bit of content, then you could also encode the relationships in that schema. There may not be sufficient information about the alternate URIs given to make informed use of an alternate encoding, and there may be a desire to shoe-horn the links into improper relationships. I don't believe that 'alternate' is the same as 'equivalent'. I would be wary encoding 'alternate' relationships into most schemas, as you're then dealing with two identities that you may be expressing relationships between; the abstract concept of the content vs. the specific encoding of the content (so, 'the metadata describing <dataset>' vs. 'the metadata describing <dataset> in XML')
As we don't have a good model like FRBR to deal with these sorts of specifics, I have a feeling that it would cause more harm than good. Per my paper, "FRBR Applied to Scientific Data" (preprint at http://vso1.nascom.nasa.gov/vso/misc/jhourcle_ASIST_2008.pdf ), the 'alternate' relationship that we discuss would be between Manifestations of the same Expression or different Expressions. The relationship between landing pages for other data collections would be between Works.
-Joe
>> If you are willing to undertake these changes, please submit your revised manuscript <https://peerj.com/manuscripts/3509/edit/> (with any rebuttal information*) to the journal within 45 days.
>> * Resubmission checklist:
>>
>> When resubmitting, in addition to any revised files (e.g. a clean manuscript version, figures, tables, which you will add to the "Primary Files" upload section), please also provide the following two items:
>>
>> A rebuttal Letter: A single document where you address all the Editor and reviewers' suggestions or requirements, point-by-point.
>> A 'Tracked Changes' version of your manuscript: A document that shows the tracking of the revisions made to the manuscript. You can also choose to simply highlight or mark in bold the changes if you prefer.
>>
>> Accepted formats for the rebuttal letter and tracked changes document are: docx (preferred), doc, or PDF.
>>
>>
>> Harry Hochheiser
>> Academic Editor for PeerJ
>>
>>
>> Reviewer 1 (Anonymous)
>>
>> Basic reporting
>>
>> No Comments
>>
>> Experimental design
>>
>> No Comments
>>
>> Validity of the findings
>>
>> No Comments
>>
>> Comments for the author
>>
>> The new draft is more thorough, clear, and readable.
>>
>