Thanks, this is brilliant! I did not know you were moving open source, we might just contribute some attempt to do that RDF support.
On Tue, Mar 12, 2013 at 6:20 PM, Gudmundur A. Thorisson <[email protected]> wrote: > Hi all. Thanks a bunch to @hvdsomp for highlighting this discussion on > Twitter earlier. > > Here's a collective response from the ORCID camp, which includes Laure > (executive director), Laura (technical director), Rob (lead developer), > myself and others involved in day-to-day operations in one way or another. > > > First, on a purely technical level, Stian's absolutely correct that the > central ORCID systemis misbehaving by stating it's returning RDF, when it's > actually responding with XML. I'll submit a bug report and try and push to > get this fixed ASAP, to avoid further confusion. Actually, strike that: looks > like Rob is already on it (see Github info below). > > Second, concerning RDF support more generally, we are aware that Linked Data > interop is becoming increasingly important. There have been discussions > around this topic within the ORCID project but, as noted earlier on this > thread, there simply isn't bandwidth to address this need right now. ORCID > plans to start working on RDF requirements later this year, and welcomes > community input into the process. > > Highly relevant to this, a major recent development is that ORCID's code is > now open source and the community can participate in helping to address > issues such as this one. More info here: > > http://orcid.org/blog/2013/02/21/orcid-open-source > http://orcid.org/about/community/orcid-technical-community > https://github.com/ORCID/ORCID-Source <-- for those who like to get straight > to the business of coding! > > Also, this just arrived from Github: > > On 12.3.2013, at 17:47, Robert Peters <[email protected]> wrote: >> Subject: [ORCID-Source] Stop matching wild on wild card (#40) > >> Pushing this out early just so external people can see what is going on. >>. >> 1) Still need to do some nginx work on production >> 2) Still need to do more integration testing. > ... >> Or view, comment on, or merge it at: >> https://github.com/ORCID/ORCID-Source/pull/40 > > > > > Hope this helps! > > > > Don't hesitate to get in touch, either directly (Laure <[email protected]>, > Laura <[email protected]>, Rob <[email protected]> or myself) or via the > feedback/support website at http://support.orcid.org . > > > Best regards, > > > Mummi > > -- > Gudmundur A. Thorisson, PhD > Project manager, ORCID - http://orcid.org | ODIN project - > http://odin-project.eu > Project manager, Institute of Life and Environmental Sciences, University of > Iceland - http://luvs.hi.is > Open Access Iceland - http://opinnadgangur.is > http://gthorisson.name | http://orcid.org/0000-0001-5635-1860 | > http://twitter.com/gthorisson > > > > On 12.3.2013, at 17:01, Alan Ruttenberg <[email protected]> wrote: > >> >> >> On Tue, Mar 12, 2013 at 12:48 PM, Stian Soiland-Reyes >> <[email protected]> wrote: >> (Thanks anyone for helpful comments!) >> >> On Tue, Mar 12, 2013 at 3:42 PM, Alan Ruttenberg >> <[email protected]> wrote: >> >> > Not to be too much of a stickler, but that isn't a spec, and isn't a clear >> > statement. For instance the scope of "unique" isn't clear, and I can, with >> > little effort, imagine a scenario where that uniqueness means that no two >> > researchers have the same identifier (but can have more than one), but they >> > identify names, and that the "transparent" method is that they have >> > equivalences among the names. >> >> Just to clarify ; ORCIDs are (at least now) claimed by authors >> themselves, so for instance me (as on >> http://orcid.org/0000-0001-9842-9718 ) covers both publications by >> "Stian Soiland-Reyes" and my previous name "Stian Soiland" (which is >> listed as 'Also known as'). >> >> Now unlike the various J Smith's, I'm quite lucky in that my new name >> is (so far!) unique in the world, but without ORCID there could be >> trouble ahead if my son (same initial S) would become a scientist. >> >> >> >> > As for the comments about ORCIDS not being suitable for linked data, that >> > is >> > a very narrow view. Having a large system of person identifiers that many >> > organizations agree they will use means that there's the possibility of >> > linking what the people do very easily. That ORCID itself doesn't supply >> > resolvable URIs (yet) doesn't mean that others can't use those identifiers >> > when publishing information as linked data. And if they do it will be very >> > very useful. >> >> Exactly, this is why we want to use ORCID! :) >> >> The current problem is that the URIs ARE resolvable, and they DO claim >> to return application/rdf+xml although it is not - so it seems like a >> bit of a disconnect with the whole web architecture regardless of them >> exposing RDF or not. >> >> It's just an error. They can and will fix it, I'm sure - they are pretty new >> and I expect overburdened at the moment. Have you all made sure that they >> have received the feedback (and suggested resolution) through the >> appropriate channels? >> >> >> >> > So back to clarification. We need to know what the ORCID identifies >> > (pair(name, person) or person), and what the definitive URI is for that >> > ORCID. (let's have one case be UO1) >> >> I agree that both of these should be clearly specified by ORCID. It >> is not the pair with the name, as I have shown for my own profile; but >> it's unclear if an ORCID identifies a person (me) or a scientist (ie. >> could I put my ORCID as the creator of my family photos?). >> >> Well, you have shown a use that is not that. But that doesn't define how it >> will in fact be interpreted. >> >> >> I know such nitpicking that could go very deep ("me yesterday with a >> red t-shirt!") - but some clarification is needed to know if we can >> call them foaf:Person's or just something related to such persons. >> >> It needs to go as deep as necessary. But certainly knowing that these are >> identifers for foaf:Person's, and there will be no more than one per >> foaf:Person solves much of the issue. Note, however, that foaf itself is a >> bit problematic, as the doc says a foaf:Person can be imaginary, and a) I >> don't know what an imaginary person is b) I don't think ORCID contemplates >> imaginary researchers - how would an imaginary person claim their ORCID? >> >> >> (For instance, W3C PROV has the concept of prov:specializationOf which >> could be appropriate on a prov:Person, for instance when the person >> prov:actedOnBehalfOf an organization. >> http://www.w3.org/TR/prov-o/#specializationOf - in this model the >> ORCID URI can still identify an agent). >> >> I don't understand this comment. I don't want to get into too much of a >> conversation about PROV, but clearly, in the world we live in, that >> "specialization" is still the same Person. I would therefore expect there to >> be one, not two ORCIDs even though there are two "web" instances. >> >> >> > I would then expect many other groups to publish information whose >> > foaf:primaryTopic is what the above URI identifies. >> >> OK.. so to take Kingsleys example you would expect my server >> example.com (which has nothing to do with orcid) to say: >> >> >> > GET http://example.com/stian.rdf HTTP/1.1 >> >> 200 OK HTTP/1.1 >> Content-Type: text/turtle >> >> <> a foaf:PersonalProfileDocument ; >> foaf:primaryTopic <http://orcid.org/0000-0001-9842-9718> ; >> >> <http://orcid.org/0000-0001-9842-9718> a foaf:Person ; >> foaf:name "Stian Soiland-Reyes" . >> >> >> Looks reasonable to me. >> >> >> >> ? >> >> I thought a foaf:PersonalProfileDocument was one which foaf:maker was >> its foaf:primaryTopic. Now I feel I can't go and make "personal" FOAF >> profiles for people I find in ORCID - so I can do the above in my own >> FOAF file, but I can't do that when I simply want to talk about >> someone else. >> >> Sure. "The PersonalProfileDocument class represents those things that are a >> Document, and that use RDF to describe properties of the person who is the >> maker of the document. There is just one Person described in the document, >> ie. the person who made it and who will be its primaryTopic." >> >> But you can make other classes of document that are like >> PersonalProfileDocument but without the constraint that the document creator >> is the same as the primary topic. PersonalProfileDocument would be subclass >> of those class. You (or foaf) could even add an axiom that says all >> instances of PersonalProfileDocument are created by the same as the primary >> topic. You would then have a clear differentia between your broader class >> and PersonalProfileDocument >> >> Regards, >> Alan >> >> >> >> >> -- >> Stian Soiland-Reyes, myGrid team >> School of Computer Science >> The University of Manchester >> > > > -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester
