2013 11 20 rdf fixes

[stain]

This proposed patch fixes a few outstanding issues with the FOAF RDF from ORCID (e.g. from https://pub.orcid.org/experimental_rdf_v1/0000-0001-6938-0820 )

• rdfs:label was wrong when ORCID Published name was not set (avoids rdfs:label "org.orcid.jaxb.model.message.GivenNames@85e2bd83" )
• country indicated with geonames:countryCode (but not yet by URL - I tried to get a small datadump to get URIs and names per countrycode from http://sws.geonames.org/ but did not finished it in time)
• foaf:account now goes to the ORCID URI with a trailing / - e.g. http://orcid.org/0000-0001-9842-9718/ - this means the URI actually works in a browser (before it was /orcid-bio which only works at API endpoint)
• Author URLS declared with name "WebID" are exposed as owl:sameAs in FOAF (stronger than the current "FOAF") - this can be used to strongly link the ORCID web identifier with any existing identifier

Note that I have not been able to this on a full system, although the unit tests in org.orcid.api.common.writer.rdf.RDFWriterTest verify that the modifications work.

[stain]

I updated the patch to include the actual country information.

See https://gist.github.com/stain/7568062 for partial example.

[rcpeters]

Awesome! All the Integration and unit test pass. Merging. I'll also deploy to sandbox today and repost on this thread to give you a chance to test before going live.

[stain]

Thanks! Looking forward to test it live.

On Thu, Nov 21, 2013 at 7:34 PM, Robert Peters notifications@github.comwrote:

Awesome! All the Integration and unit test pass. Merging. I'll also deploy
to sandbox today and repost on this thread to give you a chance to test
before going live.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/656#issuecomment-29015838
.

Stian Soiland-Reyes
Manchester, UK
http://soiland-reyes.com/

[stain]

I realized that http://orcid.org/0000-0001-9842-9718/ with the final slash

• which I used as the ID for the "account" or "profile page" (rather than
  the "person" which we all agree is http://orcid.org/0000-0001-9842-9718)
  requires authentication in the browser (by a 302 to /signin)

Is this intentional? The URL with / redirects correctly if I ask for RDF:

c:\Users\stain>curl -L -H "Accept: text/turtle"
http://orcid.org/0000-0001-9842-9718/

Perhaps there is another URL I could use that would give the same content
as http://orcid.org/0000-0001-9842-9718 but which would always be the HTML
version (e.g. the "orcid profile" as opposed to the "orcid person") -- I
initially tried to use
http://orcid.org/0000-0001-9842-9718/orcid-profilefor this, but that
URL does not work in the browser.

On Fri, Nov 22, 2013 at 1:31 PM, Stian Soiland-Reyes <
stian@soiland-reyes.com> wrote:

Thanks! Looking forward to test it live.

On Thu, Nov 21, 2013 at 7:34 PM, Robert Peters notifications@github.comwrote:

Awesome! All the Integration and unit test pass. Merging. I'll also
deploy to sandbox today and repost on this thread to give you a chance to
test before going live.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/656#issuecomment-29015838
.

Stian Soiland-Reyes
Manchester, UK
http://soiland-reyes.com/

Stian Soiland-Reyes
Manchester, UK
http://soiland-reyes.com/

[rcpeters]

Hi Stan - your code is on sandbox-1.orcid.org. With URLs I'll have to talk to some people. I would guess what your are seeing isn't likely to change, since we always want people to use http://orcid.org/0000-0001-9842-9718 when sharing their ORCID iD. If we support an alternative url for displaying the html record we will have two issues. 1 users will start sharing more then one url. 2 search engines will likely start flagging pages as duplicate content, or flagging the wrong pages.

Given that making the case for 301 redirecting http://orcid.org/0000-0001-9842-9718/ to http://orcid.org/0000-0001-9842-9718 should be easy to make. However I'm not sure you would consider that a suitable answer?

[gthorisson]

Hi Stian. I did some poking around in the ORCID RDF (and looked briefly at the FOAF spec) and realized that the foaf:account property is a pointer to an instance of the foaf:OnlineAccount class defined elsewhere in the RDF document:

<http://orcid.org/0000-0001-5635-1860/orcid-profile>
      a       foaf:PersonalProfileDocument , foaf:OnlineAccount ;
      rdfs:label "0000-0001-5635-1860" ;
 [.. some more triples]

So, in principle I suppose it does not matter whether this URI actually resolves or not, as it's only used to identify the account entity. Would it perhaps solve the issue to make the foaf:account property a local, within-document reference instead of a global URI?

[stain]

Yeah, I think that would be easier, just #account or something. It is not
an accessible thing.. I reused /orcid-profile as it was in rest interface,
but that didn't work on public web, neither for browsers or asking for json.

However for foaf:publications that is not so good.. I'll have a look at
the mappings and see what could make sense. Perhaps an anchor that appears
in the html would work, or we make the json url for publication
(/orcid-publications ?) also work for browsers (redirecting to the front
page of an account).

Have you had any further thoughts on how to display the publication list in
rdf?
On 22 Nov 2013 15:51, "Gudmundur A. Thorisson" notifications@github.com
wrote:

Hi Stian. I did some poking around in the ORCID RDF (and looked briefly at
the FOAF spec) and realized that the foaf:account property is a pointer
to an instance of the foaf:OnlineAccount class defined elsewhere in the
RDF document:

http://orcid.org/0000-0001-5635-1860/orcid-profile
a foaf:PersonalProfileDocument , foaf:OnlineAccount ;
rdfs:label "0000-0001-5635-1860" ;
[.. some more triples]

So, in principle I suppose it does not matter whether this URI actually
resolves or not, as it's only used to identify the account entity. Would it
perhaps solve the issue to make the foaf:account property a local,
within-document reference instead of a global URI?

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/656#issuecomment-29082660
.

[gthorisson]

sorry, this dropped off my radar and I forgot to reply!

I don't yet have a firm idea about RDF-zing the works listing. But this is something we're planning to spend some time looking into in ODIN (http://odin-project.eu), as part of the Interoperability work package. We have a simple Ruby app (http://feed.labs.orcid-eu.org/) which sits in front of the ORCID API and generates a works feed in various formats. This app could serve as a handy playground for RDF experimentation.

It'd be great if you could be in the loop and advise on this work in coming months!

[stain]

Sure, keep me involved! I'm not sure how much time I can commit as I have
just moved on to a new project, but would love to stay in touch as you move
closer to putting up such a prototype.

Perhaps it would also be good to talk about what would be the intended use
of the Linked Data version of works; personally I would like to use them as
anchor points for related Research Objects (see
http://researchobject.org/), we currently face an issue with many
papers not having DOIs or even
persistent IRIs.

Just having some semi-central place to look up the corresponding
publication means we can make a 10-click operation to perhaps two clicks.
For us the main information needed would be the biographical ones: authors,
title, journal/conference, year, but even more so any clickable URLs to the
actual paper (even if paywalled), as with dx.doi.org.

I know other sites like ResearchGate also have this information, but I get
the feeling they are more of a Facebook-like silos; Orcid is much more
inviting as an open-ended (if not as detailed) architecture with data
flowing both ways.

Perhaps the possibility to give outgoing links from a publication to it's
research object could be interesting to Odin? It would become a central
point where to add links to Datacite, scripts and methods, slideshares, etc.

Looking forward to your thoughts!
On 2 Dec 2013 15:45, "Gudmundur A. Thorisson" notifications@github.com
wrote:

sorry, this dropped off my radar and I forgot to reply!

I don't yet have a firm idea about RDF-zing the works listing. But this is
something we're planning to spend some time looking into in ODIN (
http://odin-project.eu), as part of the Interoperability work package. We
have a simple Ruby app (http://feed.labs.orcid-eu.org/) which sits in
front of the ORCID API and generates a works feed in various formats. This
app could serve as a handy playground for RDF experimentation.

It'd be great if you could be in the loop and advise on this work in
coming months!

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/656#issuecomment-29628036
.

[gthorisson]

[switching conversation from Github to private E-mail]

[gthorisson]

[switching conversation from Github to private E-mail]