More Signposting at DataCite

12 views
Skip to first unread message

Herbert Van de Sompel

unread,
Nov 14, 2016, 6:38:31 AM11/14/16
to signposting, Herbert Van de Sompel
HI all,

Martin Fenner is also implementing an additional Signposting pattern on the Contributor pages of DataCite Search.

For example, for Geoff Bilder's page <https://search.datacite.org/contributors/0000-0003-1315-5960>:

HTTP/1.1 200 OK
Server: openresty/1.11.2.1
Date: Mon, 14 Nov 2016 11:24:27 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 34445
Connection: keep-alive
Status: 200 OK
Link: <http://orcid.org/0000-0003-1315-5960> ; rel="identifier"
Access-Control-Allow-Origin: *
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Powered-By: Phusion Passenger 5.0.30
Access-Control-Allow-Headers: Content-Type,Accept,Accept-Encoding,Origin,User-Agent,Cache-Control,Keep-Alive

This one gave me a moment pause as I was wondering: Should this be an "identifier" or an "author" relation type? Martin is correct that it should be "identifier" IMO. 

But this situation does highlight something I did discuss at the very end of my PIDapalooza presentation, last week, see <http://www.slideshare.net/hvdsomp/pid-signposting-pattern>: 

During the conference, I learnt that PIDs are now being minted not just for scholarly texts, datasets, and contributors, but also for e.g. projects, organizations, events, instruments, platforms (e.g. a ship on a scientific mission), etc. Given this reality, I think it would be very useful to be able to indicate the kind of resource a PID identifies. I think that doing this at a very high, not a detailed level, would already be really helpful. And it would not preclude having terms with finer granularity.

This typology could be conveyed in 2 ways:
- As a "sem-type" attribute on a link with an "identifier" relation type. As such, a client that interacts with a resource like the one listed above, could immediately understand that the identifier to which is linked, is one for a contributor.
- As a link with the "type" relation type at the PID itself, e.g. in the above case one would have a "type" link at the ORCID URI.

One would obviously have to mint URIs to express these types, e.g. http://signposting.org/types/contributor , http://signposting.org/types/event, etc. I am not expressing any preference for namespace nor nomenclature. Just indicating that these types needs to be expressed as URIs.

Ideas anyone? 

Greetings

Herbert

--
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/
http://orcid.org/0000-0002-0715-6126

==

Paul Walk

unread,
Nov 14, 2016, 9:22:17 AM11/14/16
to Herbert van de Sompel, signposting
Really good to see some implementations appearing - good stuff!

Just on the idea: "I think it would be very useful to be able to indicate the kind of resource a PID identifies":

I guess I'm a little unconvinced by this. I would argue for being ruthless about keeping the level and complexity of metadata to the minimum necessary to serving the 'signposting' function. If it's the resource which is being classified (e.g. as 'platform' or 'event') and not the PID, then I think this classification should be done in a different place (typically through a metadata record associated with the resource). Of course a rel pointing to this metadata record is perfectly viable.

Cheers,

Paul
> --
> You received this message because you are subscribed to the Google Groups "signposting" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to signposting...@googlegroups.com.
> To post to this group, send email to signp...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/signposting/CAOywMHdk_yC0g5kFQkKgS9c9j%3DxWXvL9PDLX92miBMQF%3DaUF3Q%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-------------------------------------------
Paul Walk
http://www.paulwalk.net
-------------------------------------------





Reply all
Reply to author
Forward
0 new messages