| Time |
S |
Nick |
Message |
| 12:09 |
|
|
jwhitney joined #dvn |
| 12:11 |
|
pdurbin |
jwhitney: good morning! |
| 12:11 |
|
jwhitney |
pdurbin: hello! |
| 12:11 |
|
pdurbin |
lots of stuff happening on this end! :) |
| 12:12 |
|
pdurbin |
hopefully stuff you like... new features mostly... but a few changes as well |
| 12:17 |
|
pdurbin |
jwhitney: when you get a chance, can you please scroll to the bottom of this and check out my comment about "lookup a single dataverse"? DVN SWORDv2 implementation design document: https://docs.google.com/document/d/1Sw8ZTjelFtWIi1etWqgQ0gPh6ltJuh8voX00WUi7Sng/edit?usp=sharing |
| 12:22 |
|
jwhitney |
pdurbin: that's fine -- the plugin accommodates this quite happily |
| 12:22 |
|
jwhitney |
pdurbin: a lookup has to occur after username / password entered, so just as easy to select from multiple possible dataverses |
| 12:24 |
|
pdurbin |
jwhitney: great. I figured you weren't relying on a single SWORD collection being returned in the Service Document but I wanted to make sure |
| 12:25 |
|
pdurbin |
jwhitney: I think the other changes I want to communicate are captured here: https://github.com/dvn/dvn-devguide-src/commits/master |
| 12:26 |
|
pdurbin |
i.e. the commits behind the curl examples at http://devguide.thedata.org/features/api/data-deposit/v1 |
| 12:26 |
|
pdurbin |
jwhitney: so, a big one is this: "replace all files" no longer supported |
| 12:27 |
|
pdurbin |
"replace all files" no longer supported · 1d5c36b · dvn/dvn-devguide-src - https://github.com/dvn/dvn-devguide-src/commit/1d5c36b |
| 12:28 |
|
pdurbin |
we're concerned about inefficiency... we want people to delete individual files instead and add new files if they need to |
| 12:30 |
|
jwhitney |
pdurbin: yes, ok, that works here. |
| 12:33 |
|
pdurbin |
jwhitney: great. the "delete file" and "add files" curl commands are on that page |
| 12:34 |
|
jwhitney |
pdurbin: I see, yes. So it's little different to post new a zip of new files & delete individual files |
| 12:34 |
|
jwhitney |
pdurbin: rather than a full replace |
| 12:34 |
|
pdurbin |
right, exactly |
| 12:35 |
|
pdurbin |
jwhitney: if you read my note at https://github.com/IQSS/dvn/blob/aac0e952c47c6f1bd1379bdfc6b70d9e068f7796/src/DVN-web/src/edu/harvard/iq/dvn/api/datadeposit/MediaResourceManagerImpl.java#L119 you'll see my thoughts on this method |
| 12:36 |
|
pdurbin |
in short, the SWORD spec says that perhaps some kind of versioning could be done in the case of a replace. but for now I just throw an error. maybe in the future we'll support this method with versioning but not in v1 |
| 12:39 |
|
pdurbin |
jwhitney: I just wanted to make sure you're aware of this change because "replace all files" used to be the main way to add files to a study |
| 12:46 |
|
jwhitney |
pdurbin: that's great -- thanks for filling me in. Only minor changes here -- different swordappv2 library call to post rather than put |
| 12:47 |
|
pdurbin |
right, makes sense |
| 12:49 |
|
pdurbin |
jwhitney: in the past we've talked about our files on the DVN side have metadata such as filename, category, and description. I don't have a way to set descriptions for files. Is this a problem for the OJS use case? See also this ticket about this: https://redmine.hmdc.harvard.edu/issues/3232 |
| 13:15 |
|
pdurbin |
jwhitney: does that makes sense? I'm trying to ask if it's ok if we don't populate "description" for each file on the DVN side |
| 13:17 |
|
jwhitney |
pdurbin: for now, yes, I think so. OJS gives authors the option to add metadata to supplementary files (title, creators, keywords, etc.) that may differ from article-level metadata for these fields. |
| 13:19 |
|
jwhitney |
pdurbin: so potentially, ojs is collecting more metadata than can currently be sent over to dataverse, unless some of the file-level metadata is propagated upward to fill in absent study-level fields |
| 13:19 |
|
jwhitney |
pdurbin: although that's probably not a great idea |
| 13:20 |
|
pdurbin |
jwhitney: right, OJS is collecting more metadata about files and it wouldn't all appear on the DVN side |
| 13:21 |
|
jwhitney |
pdurbin: yep |
| 13:21 |
|
pdurbin |
jwhitney: I'm looking at your screenshot at author_describe_datafile.png - Google Drive - https://docs.google.com/file/d/0B8Zfl4GMgyejMVV2VUV6QkptN3M/edit |
| 13:22 |
|
pdurbin |
looks like for a file in OJS, you can have Title, Author(s), Keywords, Brief description, Category, and Date |
| 13:22 |
|
jwhitney |
pdurbin: yes, this is based on the supplementary file upload |
| 13:23 |
|
pdurbin |
jwhitney: to support all this, you and I would need to agree on some sort of manifest file, I guess... or some other way to store all this information within the zip file that is sent across via SWORD |
| 13:24 |
|
jwhitney |
pdurbin: I'm wondering if it's better to capture file-level metadata that's only available OJS side, or use a simpler interface to only capture what Dataverse will currently store |
| 13:25 |
|
pdurbin |
jwhitney: oh, are you saying you could expose only a few fields on the OJS side? Only the fields we can receive on the DVN side? (filename and category) |
| 13:27 |
|
jwhitney |
pdurbin: that's what I'm wondering: if that approach would be too limiting for submitters |
| 13:27 |
|
pdurbin |
it might feel limiting, yes |
| 13:27 |
|
|
posixeleni joined #dvn |
| 13:27 |
|
posixeleni |
hi pdurbin and jwhitney! |
| 13:28 |
|
pdurbin |
but it would probably be frustrating for submitters if they filled in a bunch of fields that don't get propogated to the DVN side |
| 13:28 |
|
jwhitney |
hello! |
| 13:28 |
|
jwhitney |
pdurbin: agreed |
| 13:28 |
|
pdurbin |
posixeleni: are you following this? |
| 13:28 |
|
pdurbin |
posixeleni: and hello! :) |
| 13:29 |
|
posixeleni |
i saw you chatting about the invidiviual file level metadata and just wanted to ask a quick question about how OJS would capture send over to us about the overall metadata for the Dataverse study |
| 13:29 |
|
pdurbin |
posixeleni: oh, well, that's different... study-level metatadat |
| 13:29 |
|
posixeleni |
we got that covered right? |
| 13:30 |
|
pdurbin |
well, let's finish the file-level metadata (i.e. description) discussion |
| 13:30 |
|
pdurbin |
for now anyway :) |
| 13:30 |
|
posixeleni |
cool sorry to interrupt! |
| 13:30 |
|
pdurbin |
I'm in favor of limiting the visible fields on the OJS side to what we can receive on the DVN side (filename and category) |
| 13:31 |
|
pdurbin |
I realize this is limiting, but I'm more worried about the frustration submitters would feel when they realize the description, etc. doesn't get propogated to the DVN side |
| 13:31 |
|
jwhitney |
I agree -- otherwise, I think it's misleading to collect metadata that doesn't get deposited |
| 13:32 |
|
pdurbin |
yeah |
| 13:32 |
|
jwhitney |
also, I type slowly. |
| 13:32 |
|
jwhitney |
:) |
| 13:32 |
|
pdurbin |
and on the DVN side, we don't even have some of those fields on the file level, such as Author |
| 13:32 |
|
pdurbin |
:) |
| 13:33 |
|
jwhitney |
yes, and I think it makes more sense to extend the plugin if / as DVN changes |
| 13:33 |
|
pdurbin |
again, for description (which we do have at the file level), I opened a ticket to maybe support populating description for each file inside a zip file in the future (not v1): https://redmine.hmdc.harvard.edu/issues/3232 |
| 13:34 |
|
pdurbin |
jwhitney: right. this is v1. we want feedback from actual users of the plugin |
| 13:35 |
|
jwhitney |
pdurbin: ok, that's great |
| 13:35 |
|
pdurbin |
posixeleni: I think you can go ahead now :) |
| 13:35 |
|
pdurbin |
jwhitney: thanks |
| 13:35 |
|
pdurbin |
jwhitney: it's no fair, two against one ;) |
| 13:36 |
|
pdurbin |
ruebot: you can be on jwhitney's side ;) |
| 13:37 |
|
pdurbin |
jwhitney: the last thing I want to talk about is the FIXMEs at https://github.com/IQSS/dvn/blob/cdb2ceb61ec661929eabe84adadbda04ae047d14/tools/scripts/data-deposit-api/atom-entry-study.xml |
| 13:38 |
|
posixeleni |
jwhitney: good morning!! just wanted to get an idea as to how OJS would capture/send to us the overall metadata for a Dataverse study which would normally include "Author", "Title" (of the article), Date, etc |
| 13:38 |
|
pdurbin |
studyRelPublication.getIdType() vs. getIdNumber() vs. getUrl() |
| 13:39 |
|
jwhitney |
posixeleni: hi there! going through your message from yesterday |
| 13:41 |
|
pdurbin |
posixeleni: are you talking about the FIXMEs too? or something else? |
| 13:46 |
|
posixeleni |
jwhitney: i think i needed to get my coffee BEFORE I typed out that message... :/ |
| 13:46 |
|
jwhitney |
posixeleni: lol. |
| 13:48 |
|
posixeleni |
Phil and I are working on perfecting the atom entry file here that includes all the overall metadata about the data which gets deposited into a Dataverse Study https://github.com/IQSS/dvn/blob/develop/tools/scripts/data-deposit-api/atom-entry-study.xml |
| 13:49 |
|
jwhitney |
posixeleni: ok, let's start w/ the article citation -- I have a slight preference for using dcterms:isReferencedBy |
| 13:49 |
|
posixeleni |
just wanted to make sure I understood where all this info would be captured from your side (which definitely refers to the email I had written to everyone yesterday) |
| 13:50 |
|
posixeleni |
jwhitney: i can definitely agree with that... i'm guessing Alex will be cool with this as well? |
| 13:51 |
|
jwhitney |
posixeleni: well, let's find out. Will ask him to catch up here. |
| 13:55 |
|
posixeleni |
jwhitney: thanks! |
| 13:58 |
|
pdurbin |
jwhitney: I'm so glad you and posixeleni have opinions about which dcterms fields to use... Dublin Core is very new to me :) |
| 13:59 |
|
jwhitney |
pdurbin: well, that was a fast call, but mainly based on the thought that a data file may be referenced by multiple studies / articles. |
| 14:00 |
|
jwhitney |
pdurbin: to me, isPartOf suggests that it belongs solely to one study / article. |
| 14:03 |
|
jwhitney |
but no strong feelings either way. |
| 14:06 |
|
pdurbin |
jwhitney: ok. do you agree with the sentiment that we need 4 dcterms fields? 1. The related publication citation 2. ID type (i.e. DOI, arXiv) 3. ID number (i.e. DOI number) 4. ID URL (i.e. http://dx.doi.org/10.1093/rfs/hhm055 ) |
| 14:07 |
|
jwhitney |
pdurbin: yes, unless you want to generate #4 from 2 & 3 |
| 14:09 |
|
jwhitney |
pdurbin: although that could become unwieldy / limiting |
| 14:10 |
|
pdurbin |
jwhitney: well, in practice I'm seeing many URLs in our database that are not on http://dx.doi.org ... stuff like http://www.mitpressjournals.org/doi/abs/10.1162/REST_a_00194 and http://onlinelibrary.wiley.com/doi/10.1111/j.1528-3585.2011.00436.x/abstract ... I don't know how I'd construct those URLs... |
| 14:10 |
|
pdurbin |
the non-doi.org URLs I mean |
| 14:10 |
|
jwhitney |
pdurbin: yes, I was thinking too narrowly |
| 14:12 |
|
pdurbin |
jwhitney: related to this I had written this in an email: "I'm going to see if I can use a single dcterms field for DOI + number (separated by a colon) but separate fields was easier for me to get working quickly." |
| 14:12 |
|
jwhitney |
pdurbin: so ok, 4 fields to get at the citation & permalink |
| 14:12 |
|
pdurbin |
but now I'm not so sure about splitting on a colon, after talking to posixeleni this morning |
| 14:13 |
|
pdurbin |
that is to say, I'm not sure I should hard code the split on a colon. i.e. DOI:0.1234/ABCD |
| 14:14 |
|
pdurbin |
to separate the type (DOI vs. arXiv vs. ???) and the identifier (10.1234/ABCD) |
| 14:14 |
|
pdurbin |
(sorry, I meant to put 10. in the i.e.) |
| 14:16 |
|
pdurbin |
jwhitney: what do you think? I hope this makes sense. The thing I'm wondering is if we should try to use a single dcterms field to represent the type (agency) and the id... and assume they are always separated by a colon |
| 14:18 |
|
jwhitney |
my preference is for separate fields, but not sure we can squeeze them out of dc |
| 14:18 |
|
posixeleni |
pdurbin: my concern is that Dublin Core even with the extended DCMI terms is still too flat so it would be difficult to break the citation down into mutliple DC terms |
| 14:18 |
|
posixeleni |
that would relate to each other |
| 14:18 |
|
pdurbin |
yeah, I hear you. both of you |
| 14:19 |
|
pdurbin |
well, maybe I'll work a bit on splitting on colon in the xslt stylesheet in case we need it |
| 14:21 |
|
pdurbin |
speaking of flat... technically in DVN and DDI, you can have multiple of these related publications (relPubl). But I don't think we can support this in the atom-entry-study.xml file since dcterms is so flat |
| 14:22 |
|
posixeleni |
we could have more than one citation like we have more than one author? |
| 14:24 |
|
pdurbin |
posixeleni: you mean isPartOf? (which may become isReferencedBy if jwhitney gets her way.) The text of the OJS article citation? well, how do you later associate the type, id, and url if there is more than one citation? |
| 14:25 |
|
pdurbin |
right now I have it coded such that the 4 fields all go into the same "related publication" |
| 14:25 |
|
pdurbin |
jwhitney: have you seen how this looks on the DVN side? |
| 14:26 |
|
jwhitney |
pdurbin: not since last week |
| 14:26 |
|
posixeleni |
pdurbin: yeah i see what you mean... all this info would have to be smooshed into a isPartOf or isReferencedBy field |
| 14:29 |
|
pdurbin |
jwhitney: here's how it looks. See "Publications" which has a Link? http://dvn-build.hmdc.harvard.edu/dvn/dv/pdurbin1/faces/study/StudyPage.xhtml?globalId=hdl:TEST/10013 |
| 14:30 |
|
pdurbin |
that's the end goal, basically |
| 14:30 |
|
pdurbin |
populate those 4 fields |
| 14:30 |
|
pdurbin |
especially the link, I'd say, since it's pretty fundamental to how we're trying to link data and articles: http://projects.iq.harvard.edu/files/styles/os_files_xlarge/public/ojs-dvn/files/ojs-dvn-integration.png |
| 14:32 |
|
jwhitney |
pdurbin: yes, sorry -- familiar w/ that, thought you meant changes to the atom entry \ |
| 14:34 |
|
pdurbin |
jwhitney: well, the atom entry is what we'll use to populate those fields |
| 14:34 |
|
pdurbin |
the 4 fields under "Publications" on the DVN side |
| 14:37 |
|
pdurbin |
the 4 fields in the atom entry get added to those fields under "Publications" (relPubl) on the DVN side with this XML stylesheet transformation: https://github.com/IQSS/dvn/blob/87210844e1292b51e31ee4a66b563fd23a294964/working_directory/dcmi_terms2ddi.xsl#L128 |
| 14:38 |
|
pdurbin |
anyway, implemention details. but that's how we're using the atom entry |
| 14:38 |
|
jwhitney |
pdurbin: right, ok |
| 14:40 |
|
pdurbin |
obviously, we want to stop using dcterms:FIXME1 and the like :) |
| 14:41 |
|
jwhitney |
posixeleni: my dc knowledge fairly basic -- can we use qualifiers to distinguish repeated elements? |
| 14:45 |
|
posixeleni |
jwhitney: given the fields we want to qualify within isReferencedBy or isPartOf I dont see what we could use as qualifiers: http://dublincore.org/documents/usageguide/qualifiers.shtml |
| 14:48 |
|
* posixeleni |
scratches head in metadata bewilderment |
| 14:50 |
|
posixeleni |
jwhitney: let me know if you see anything! |
| 14:51 |
|
jwhitney |
posixeleni: no, I'm out of my depth, here. |
| 14:54 |
|
posixeleni |
we may very well have hit the granularity ceiling as far as DC is concerned |
| 15:35 |
|
posixeleni |
jwhitney: OK so what if we put the whole journal article publication citation flattened into a single isReferencedBy field? Would the structure be consistent enough coming from OJS that Phil could parse it on our end into the separate fields for Dataverse? |
| 15:35 |
|
posixeleni |
hope that made sense! |
| 15:37 |
|
pdurbin |
bleh. would be no fun to split a single field into 4 in the xml stylesheet but I guess I can try |
| 15:39 |
|
posixeleni |
For example I'm looking at a citation (APA) from a Co-Action journal in OJS: Kostoglou, V., & Siakas, E. (2012). Investigating higher education graduates’ entrepreneurship in Greece. Annals Of Innovation & Entrepreneurship, 3. doi:10.3402/aie.v3i0.17291 |
| 15:40 |
|
posixeleni |
Would be nice to have a hyperlink included for people to go from Dataverse back to the OJS article |
| 15:42 |
|
posixeleni |
pdurbin: but perhaps we can compromise and have both custom-XML to allow for more granularity with the journal article publication citation, and a less granular DC option available |
| 15:42 |
|
pdurbin |
posixeleni: I think a hyperlink is a must... as discussed earlier it would be hard (impossible?) to construct non-doi.org URLs |
| 15:43 |
|
pdurbin |
posixeleni: by custom-XML you mean this, bascially (I think): "The client MAY add any other metadata formats or foreign markup to the atom:entry element" -- http://swordapp.github.io/SWORDv2-Profile/SWORDProfile.html |
| 15:43 |
|
pdurbin |
but that's kinda a whole can of worms |
| 15:44 |
|
pdurbin |
jwhitney: is it even easy for you to include foreign markup when using the PHP SWORD library? |
| 15:45 |
|
pdurbin |
and what would the namespace be for the foreign markup? http://purl.org/net/dvn ? http://purl.org/net/ojs ? I don't think these exist... |
| 15:45 |
|
pdurbin |
xmlns I mean |
| 15:55 |
|
jwhitney |
pdurbin: I could include custom XML although I'd have to write a new packager to allow it |
| 15:55 |
|
pdurbin |
jwhitney: hmm. ok. and Alex just replied via email |
| 15:55 |
|
* pdurbin |
reads |
| 15:55 |
|
jwhitney |
pdurbin: I'm sure there's a schema that exists already that would allow the citation to be included in parsable fields, without creating custom XML |
| 15:56 |
|
pdurbin |
jwhitney: oh, cool! |
| 15:57 |
|
posixeleni |
FYI Alex also just responded to my email but I'm gonna grab lunch |
| 15:58 |
|
* pdurbin |
needs lunch |
| 15:59 |
|
jwhitney |
* jwhitney has more packing / shipping to do but plans to be around for a couple more hours this afternoon |
| 16:29 |
|
pdurbin |
so... I like Alex's idea a lot. gonna show posixeleni when she gets back |
| 17:19 |
|
|
axfelix joined #dvn |
| 17:27 |
|
pdurbin |
axfelix: welcome! |
| 17:27 |
|
pdurbin |
posixeleni and I are trying out your idea (in code) |
| 17:29 |
|
pdurbin |
axfelix: I like your focus on the URL... the link back to the OJS study... it's really the most important thing |
| 17:30 |
|
pdurbin |
but if that's the only dcterms field available to me, I can only populate the "Link" field under "Publications" on the DVN side |
| 17:31 |
|
pdurbin |
unless... I also store the link in the field for the citation for the Publication, like this: http://dvn-build.hmdc.harvard.edu/dvn/dv/pdurbin1/faces/study/StudyPage.xhtml?globalId=hdl:TEST/10013 |
| 17:32 |
|
pdurbin |
because if I don't populate that citation field, all you see is "Link" ... i.e. you would have to hover your mouse over "Link" to see the doi |
| 17:57 |
|
axfelix |
so the issue is basically whether we expect users to need to see the DOI in non-URL form |
| 18:00 |
|
pdurbin |
well... |
| 18:01 |
|
pdurbin |
axfelix: what you should see is "Link" and above it a non-clickable URL |
| 18:01 |
|
axfelix |
right |
| 18:02 |
|
pdurbin |
that non-clickable URL is *actually* the citation field. I'm abusing it by shoving a URL in there... because I have to put *something* in there |
| 18:02 |
|
axfelix |
ahhhh, okay, I follow now |
| 18:02 |
|
pdurbin |
if you don't (in the DVN GUI), you get "Publication citation is required if other publication data is entered" |
| 18:02 |
|
pdurbin |
ideally, we have a second dcterms field with the actual citation |
| 18:03 |
|
axfelix |
but this is separate from the existing FIXMEs, which only handled URIs |
| 18:05 |
|
pdurbin |
well, the FIXMEs were written with the idea of having 4 dcterms fields to populate the 4 fields on the DVN side |
| 18:07 |
|
pdurbin |
axfelix: instead of a non-clickable URL I could put something like "[Imported via Data Deposit API]" |
| 18:07 |
|
pdurbin |
but that's pretty ugly |
| 18:08 |
|
pdurbin |
I'd rather have the actual citation of the journal article |
| 18:09 |
|
axfelix |
are we actually out of dcterms fields on the DVN side at this point, such that we'd have to try to bring in another XSD from somewhere for the sake of the web form? |
| 18:09 |
|
axfelix |
because if so we could /try/ resolving the citation string from the DOI the way I indicated in my email, but the crossref guys claim that isn't widely deployed enough |
| 18:16 |
|
pdurbin |
axfelix: well, originally I was hoping we could have 4 dcterms fields. so maybe we are out? I'm not sure |
| 18:19 |
|
pdurbin |
axfelix: I think it's a clever hack to be able to resolve a doi on the fly via a third party website, but I really like having all the info I need in the XML file. Then I run `xsltproc dcmi_terms2ddi.xsl atom-entry-study.xml` to transform all the Dublin Core to DDI. I don't have to reach out to the internet |
| 18:20 |
|
axfelix |
yeah, you're probably right |
| 18:20 |
|
axfelix |
I need to review which fields we have left and could reasonably use here |
| 18:20 |
|
pdurbin |
awsome, that would be very helpful |
| 18:20 |
|
axfelix |
should have something for you by EOD |
| 18:21 |
|
pdurbin |
great |
| 18:21 |
|
axfelix |
need to write a ddi-dc transform for an unrelated project in the meantime... |
| 18:21 |
|
pdurbin |
:) |
| 18:21 |
|
pdurbin |
so many transforms |
| 18:21 |
|
axfelix |
it's a bit silly, but if nothing else it's a nice low-to-medium-complexity task to keep your brain humming on |
| 18:22 |
|
pdurbin |
axfelix: so on a related note... |
| 18:23 |
|
pdurbin |
the nice thing about using a single dcterms field is that I can (properly) allow multiple relPubl "related publications" in DDI and in DVN |
| 18:25 |
|
pdurbin |
I'm in favor of using multiple dcterms fields (at minimum, one for the journal article citation and one for the URL) but it means that I can only create one related publication on the DDI/DVN side |
| 18:25 |
|
pdurbin |
because dcterms is so flat |
| 18:26 |
|
pdurbin |
it's like how I can specify multiple creators but I can't specify a URL for each creator. or a Twitter handle for each creator |
| 18:30 |
|
axfelix |
so that would be a point in favour of us basically just expanding a given dcterms field however we want |
| 18:30 |
|
axfelix |
which is certainly not uncommon, even if it's not technically great practice |
| 18:31 |
|
pdurbin |
axfelix: neither you nor I are fans of spliting apart strings ;) |
| 18:31 |
|
axfelix |
yeah, at that point, I think it's more realistic to chuck some MODS in there |
| 18:32 |
|
pdurbin |
dunno what MODS is |
| 18:32 |
|
axfelix |
which complicates slightly but we are probably the hundred-thousandth people to have had this conversation :) |
| 18:32 |
|
axfelix |
it's effectively a "successor" to DC, LOC-backed, expressed in XML, superset of DC terms |
| 18:32 |
|
pdurbin |
ah |
| 18:32 |
|
axfelix |
DC is still a good lowest common denominator |
| 18:33 |
|
pdurbin |
right. hence why it's in SWORD |
| 18:34 |
|
pdurbin |
axfelix: if we use a single dcterms field, could it always have a URL in it? I definitely agree with you that the URL is the most important part |
| 18:35 |
|
posixeleni |
hey folks in a meeting but just thought of this: http://wiki.dublincore.org/index.php/User_Guide#Dublin_Core_and_Linked_Data |
| 18:35 |
|
pdurbin |
(not that I'm excited about trying to figure out how to extract a URL with an XML stylesheet) |
| 18:37 |
|
pdurbin |
posixeleni: sorry, I'm not sure what you mean |
| 18:39 |
|
posixeleni |
pdurbin: sorry just thought this part of the DC user guides related to our dilemma with linking to resources (data or journal article) |
| 18:39 |
|
pdurbin |
oooooo |
| 18:40 |
|
pdurbin |
posixeleni: you have given me an idea though! |
| 18:40 |
|
pdurbin |
are we allowed to do something like this? <dcterms:isReferencedBy href="http://dx.doi.org/10.1038/dvn333">Peets, J., & Stumptown, J. (2013). Roasting at Home. New England Journal of Coffee, 3(1), 22-34.</dcterms:isReferencedBy> |
| 18:40 |
|
pdurbin |
i.e. stick an href in there? |
| 18:41 |
|
posixeleni |
ooooh ! |
| 18:41 |
|
pdurbin |
because it totally works with xsltproc |
| 18:41 |
|
posixeleni |
axfelix: how bout them apples? |
| 18:41 |
|
posixeleni |
dont see why not? |
| 18:41 |
|
axfelix |
huh, I've never actually seen that before, but I like it |
| 18:41 |
|
pdurbin |
posixeleni: forget your meeting. come check this out :) |
| 18:41 |
|
axfelix |
and it is fairly xsl-friendly |
| 18:42 |
|
pdurbin |
axfelix: maybe we could stick the other fields in there too? type and number |
| 18:42 |
|
posixeleni |
pdurbin: almost done w/ the meeting |
| 18:42 |
|
axfelix |
yeah, go for it |
| 18:43 |
|
axfelix |
I don't have a better idea and this is fairly easy to work with |
| 18:43 |
|
posixeleni |
dc likes things flat |
| 18:43 |
|
axfelix |
and I've seen worse violations of dc :) |
| 18:43 |
|
pdurbin |
it's just crazy enough to work |
| 18:47 |
|
posixeleni |
i like having the actual citation in there to provide context into what the URL/DOI is pointing to |
| 18:47 |
|
pdurbin |
I changed href to holdingsURI and added the other two: <dcterms:isReferencedBy holdingsURI="http://dx.doi.org/10.1038/dvn333" agency="DOI" IDNo="10.1038/dvn333">Peets, J., & Stumptown, J. (2013). Roasting at Home. New England Journal of Coffee, 3(1), 22-34.</dcterms:isReferencedBy> |
| 18:47 |
|
pdurbin |
I guess it can be whatever we want |
| 18:53 |
|
pdurbin |
axfelix: but will it be easy for Jen to add those attributes? |
| 18:53 |
|
pdurbin |
man I hope so |
| 18:53 |
|
axfelix |
that's why I wanted to see which fields we still had "remaining" to play with since I know OJS doesn't fully use DC as is |
| 18:54 |
|
axfelix |
but regardless I think the href solution will be usable |
| 18:54 |
|
pdurbin |
yeah. the attributes solution |
| 18:56 |
|
pdurbin |
axfelix: so this is how it looks with all 4 fields populated on the DVN side: http://dvn-build.hmdc.harvard.edu/dvn/dv/pdurbin1/faces/study/StudyPage.xhtml?globalId=hdl:TEST/10014 |
| 18:57 |
|
pdurbin |
axfelix: as you can see, agency and IDNo are displayed together as DOI:10.1038/dvn333 (with "ID:" in front of it) |
| 18:57 |
|
pdurbin |
but what looks nice is the full citation to the journal article |
| 18:57 |
|
pdurbin |
this: http://projects.iq.harvard.edu/files/styles/os_files_xlarge/public/ojs-dvn/files/ojs-dvn-integration.png :) |
| 18:58 |
|
axfelix |
A+++ great shipping |
| 18:58 |
|
axfelix |
just need to make sure we can accommodate it on the OJS side |
| 18:58 |
|
pdurbin |
hope so |
| 19:09 |
|
|
jwhitney joined #dvn |
| 19:28 |
|
jwhitney |
hi all, catching up w/ your earlier discussion. |
| 19:29 |
|
pdurbin |
jwhitney: it was getting scary for a while... ;) |
| 19:29 |
|
jwhitney |
very cool & easy to manage, I think, as long as everyone's cool with a bit of customization of the swordappv2 lib |
| 19:29 |
|
pdurbin |
ah, I was afraid you might have to modify the php sword library |
| 19:30 |
|
jwhitney |
Subclass existing or create new packager, so minor changes, but does up the code mgmt a bit |
| 19:30 |
|
pdurbin |
jwhitney: if it helps, I've had to modify the java SWORD library: generalise getName/getFilename into getContentDispositionValue by pdurbin · Pull Request #3 · swordapp/JavaServer2.0 - https://github.com/swordapp/JavaServer2.0/pull/3 :) |
| 19:32 |
|
pdurbin |
jwhitney: we should attempt to modify our python client ( https://github.com/dvn/swordpoc/tree/master/dvn_client ) and see if we have to make modifications to the sword python library |
| 19:33 |
|
pdurbin |
we (royal we) have a pull request in for the python sword client library already as well: Bug Fixes and Updates for DVN Consumption by pjbull · Pull Request #7 · swordapp/python-client-sword2 - https://github.com/swordapp/python-client-sword2/pull/7 |
| 19:33 |
|
pdurbin |
(our python client doesn't run without those changes) |
| 19:34 |
|
jwhitney |
pdurbin: reading through... |
| 19:34 |
|
pdurbin |
jwhitney: so are you ok with having to modify the php library? sounds like kind of a pain |
| 19:34 |
|
pdurbin |
I'm trying to decide what the "right" way to do this is... |
| 19:35 |
|
pdurbin |
adding attributes to dcterms:isReferencedBy is working great on my side. and with my testing via curl |
| 19:35 |
|
pdurbin |
but I'm open to other ideas |
| 19:35 |
|
pdurbin |
I *did* go ahead and commit the change on the DVN side a few minutes ago: dcterms:isReferencedBy (and attributes) for relPubl · fe00364 · IQSS/dvn - https://github.com/IQSS/dvn/commit/fe00364 |
| 19:36 |
|
pdurbin |
so here's the latest and greatest atom entry: https://github.com/IQSS/dvn/blob/fe00364d7971763556615363576bdd2becd31cfd/tools/scripts/data-deposit-api/atom-entry-study.xml |
| 19:36 |
|
jwhitney |
pdurbin: I think it's a great solution. An (admittedly speedy) review of the two-step packager leads me to think the changes would be limited to passing in an optional array of attributes to the two-step packager's addMetadata() method |
| 19:36 |
|
pdurbin |
jwhitney: ok. well, please keep us posted. I hope it isn't too bad |
| 19:37 |
|
pdurbin |
posixeleni and I have been talking about this all day. we're pretty excited about the attributes solution |
| 19:37 |
|
jwhitney |
pdurbin: you should be! |
| 19:37 |
|
pdurbin |
heh |
| 19:37 |
|
pdurbin |
:) |
| 19:38 |
|
pdurbin |
but it's not too late to do this a more "right" way if there is one |
| 19:38 |
|
pdurbin |
though we do want to release soon... basically I want to be done done on Thursday |
| 19:39 |
|
pdurbin |
jwhitney: so I should ask if there's anything else you need! |
| 19:40 |
|
pdurbin |
axfelix: you too. anything you need? |
| 19:40 |
|
jwhitney |
pdurbin: no, I'm pretty clear that I have what I need, |
| 19:40 |
|
pdurbin |
great. but... |
| 19:41 |
|
pdurbin |
what about the bibliographicCitation as a single string? do you want separate fields for some of that? |
| 19:42 |
|
pdurbin |
since we've been talking all day about dublin core anyway ;) |
| 19:50 |
|
jwhitney |
pdurbin: as long as the study global ID comes back in the atom entry, the plaintext citation is fine |
| 19:53 |
|
pdurbin |
jwhitney: well, it doesn't appear alone, if that's what you mean. the global ID appears many times but always in a URL (handle URL, edit-media URL, statement URL) |
| 19:53 |
|
jwhitney |
pdurbin: yes, of course. Sorry, long day. |
| 19:54 |
|
jwhitney |
pdurbin: last conversation re: data citation in OJS was the plain text string was fine, and I can create / link a handle if wanted. |
| 19:57 |
|
pdurbin |
jwhitney: well, posixeleni and I were talking about exposing the persistent URL for a study anyway |
| 19:58 |
|
pdurbin |
posixeleni: i think we talked about maybe using dcterms:identifier for this? on the import side we use just a global id there, not the persistent URL... |
| 20:01 |
|
pdurbin |
well, anyway, easy to add either a global id or a persisent url if someone tells me which dcterms field to use |
| 20:01 |
|
jwhitney |
pdurbin: if a persistent URL is available, I'll definitely use it |
| 20:03 |
|
pdurbin |
jwhitney: ok, I'm just not sure if I should use dcterms:identifier to expose it since we typically use that field to mean global id, not persistent URL |
| 20:04 |
|
jwhitney |
pdurbin: ok. |
| 20:05 |
|
pdurbin |
jwhitney: but I don't want to make you have to grovel around in the bibliographicCitation for the persistent URL if there's a good dcterms field I can use |
| 20:05 |
|
* pdurbin |
looks at: SWORDv2 GET examples from dash.harvard.edu (DSpace) - Google Drive - https://docs.google.com/document/d/1vgLGhsuF-5W_KQ_h0tCEvIBP2ah0L6NRckk698ZeGCY/edit?pli=1 |
| 20:09 |
|
pdurbin |
hmm, depositReceipt.setSplashUri(study.getPersistentURL()) might work... puts this in the entry: <link href='http://hdl.handle.net/hdl:TEST/12345' rel='alternate'/> |
| 20:11 |
|
pdurbin |
deposit receipt... MAY contain an atom:link rel="alternate" element with an href attribute which points to the splash page of the item on the server |
| 20:12 |
|
pdurbin |
I don't know what a splash page is in this context, but I think this could work |
| 20:13 |
|
pdurbin |
especially with a word like "alternate" ... the non-SWORD URL |
| 20:17 |
|
pdurbin |
jwhitney: ok, added. the Xpath query you'd use is here: display persistent URL via SWORD as "alternate" · 9035b61 · IQSS/dvn - https://github.com/IQSS/dvn/commit/9035b61 |
| 20:18 |
|
pdurbin |
persistent_uri = XPath.first(entry,"//link[@rel='alternate']").attributes["href"] |
| 20:18 |
|
jwhitney |
pdurbin: excellent. |
| 20:18 |
|
pdurbin |
jwhitney: should work for your needs. if not, please let me know! |
| 20:20 |
|
jwhitney |
pdurbin: thank you. much more direct than grabbing / formatting handle refs |
| 20:22 |
|
pdurbin |
jwhitney: no problem. just added it to http://devguide.thedata.org/features/api/data-deposit/v1 too |
| 20:23 |
|
pdurbin |
oh, that reminds me, the last updated links at the bottom of the devguide work now |
| 20:23 |
|
pdurbin |
anyhoo. my turn to pick up kids today. bye all! |
| 20:24 |
|
jwhitney |
pdurbin: bye! |
