Property talk:P1662

Documentation

DOI prefix
identifier specific to a DOI registrant

Description

Unique identifier specific to a digital object identifier (Q25670) registrant, AKA DOIP; see http://tools.wmflabs.org/cite-o-meter/?about

Data type

External identifier

Domain

organization (Q43229), trade magazine (Q685935) or serial (Q2217301)

Allowed values

10(\.[1-9]\d*)+

Example

Public Library of Science (Q233358) → 10.1371
Royal Society of Chemistry (Q905549) → 10.1039

Format and edit filter validation

"10", followed by one or more instances of ["." followed by a positive integer]

Source

DOIs (note: this information should be moved to a property statement; use property source website for the property (P1896))

Formatter URL

https://doi.org/$1
http://dx.chinadoi.cn/$1
https://cite-o-meter.toolforge.org/?doip=$1

Discussion

See also http://tools.wmflabs.org/cite-o-meter/?doip=10.1039 (which may also be used as a reverse lookup tool, by modifying the final parameter). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:53, 23 October 2014 (UTC)[reply]

I like the idea but don't think it would work as proposed, since DOI prefixes are actually a bit more complicated: the registrant identifier in the case of Royal Society of Chemistry (Q905549) would actually be "1021", not "10.1021". The "10" in front is called the directory, and I think I have seen DOIs with other numbers in front, but I am not sure how to find any right now, or whether these were typos. Furthermore, registrants like Elsevier BV (Q746413) (who keep buying other publishing houses) get to operate an additional registrant identifier each time they buy another registrant. As for filtering, the registrant ID might have more than four digits (not sure here), and subdivisions are allowed. Having said all that, I would find it useful to list - on the Wikidata item for a given DOI registrant - all the DOI prefixes they are currently operating, and to adjust that information upon merger or acquisition, and doing that - as suggested - with the complete prefix rather than the registrant identifier per se would seem more natural to me because that is what people are familiar with. Last but not least, there are multiple DOI registration agencies, and I am not sure to what extent their practices differ with respect to DOI prefixes. --Daniel Mietchen (talk) 23:56, 23 October 2014 (UTC)[reply]

Useful points, thank you. The linked documents suggests that "10" is the only directory code in use at present. In the example given above, we could just store "1021", or we could continue as proposed, and also store, say, "11.1021" as a second value for the property, should that ever be used. The Source MetaData WikiProject does not exist. Please correct the name. Anyone else have a view? [Aside: perhaps the WMF could be a DOI registrant, and give DOIs in the form 10.NNNN.Qnnnnn, or, say, 10.NNNN.en:609232908 for https://en.wikipedia.org/w/index.php?title=The_King_of_Rome&oldid=609232908 ] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:18, 24 October 2014 (UTC)[reply]

Support Seems to me as proposed (entire prefix) is both more familar and resilient (shoud we ever discover directory numbers other than 10) than a registrant code property. Filtering does need to account for subdivisions, an arbitrary number of them IIUC. Edited filter informed by discussion on http://stackoverflow.com/questions/27910/finding-a-doi-in-a-document-or-page Mike Linksvayer (talk) 20:22, 24 October 2014 (UTC)[reply]

Thank you. I note that the page to which you link has some regexes, which may be useful. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:30, 24 October 2014 (UTC)[reply]

While the indicator is a number adding and comparing and ranking these numbers doesn't seem to have any meaning so I would suggest the datatype should be string. Filceolaire (talk) 17:56, 1 November 2014 (UTC)[reply]

Agreed; changed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:52, 1 November 2014 (UTC)[reply]

I'd like to further challenge the notion of the single-use constraint on this property. That's not how it works out in reality. I was looking into building a bot that would work back and forth between the CrossRef and DataCite "registrars" that handle the majority of the DOI identifier spaces. The "provider" concept from those two platforms represents an organizational entity of some kind, often containing sufficient information (e.g., ROR identifier) to uniquely identify the organization and find its representation in Wikidata. If you take something like Purdue University, there are no DOI prefixes currently. You can look at the API response from DataCite for Purdue see that there are currently 12 DOI prefixes operated by the organization with ROR ID, 02dqehb95, giving us our hook to an existing WD entity. The appropriate way to record this information would be multiple DOI prefix claims on the Purdue item, preferably with a qualifier indicating that they are administered by DataCite. If this were in place, we could have SPARQL query routes to pull all kinds of interesting information together via WD as opposed to the cumbersome process of working with provider REST APIs from CrossRef and DataCite. Skybristol (talk) 23:22, 3 June 2024 (UTC)[reply]

Wrong link

@Pigsonthewing, Filceolaire: I've tested DOI Prefix with University Library of Tübingen (Q2496347): 10.15496. The result: Statistics for De Gruyter (Q98818) (10.1515). What went wrong? --81.171.85.231 12:04, 27 April 2015 (UTC)[reply]

Possibly a problem with the tool. Have you asked its author? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:58, 27 April 2015 (UTC)[reply]

It seem to be a general problem. Wikipedia Cite-o-Meter contains only a small selection of DOI Prefixes. Even the Crossref list is not completely included. Århus State and University Library (Q3432887) (10.7146) produces the result: Statistics for Walter de Gruyter (10.1515). It would help, if Wikipedia Cite-o-Meter shows in this cases a text like: "Sorry, this DOI Prefix is not jet included in our database." On the long run Cite-o-Meter should include all numbers stored in Wikidata or P1662 should link to an other website. I've written to Dario Taraborelli and Daniel Mietchen but I haven't received an answer jet. --81.171.85.254 13:26, 30 April 2015 (UTC)[reply]

The Cite-o-Meter uses a past version of the CrossRef list, and it defaults to de Gruyter when it cannot identify a prefix. The tool was written in 2011 to demo the tracking of such publisher-level information, as opposed to the article-level metrics that started to become popular at the time, and as a complement of the page-level and file-level metrics that exist on the Wikimedia end. Apart from having been ported to Wikimedia Cloud Services (Q15041928) and D3.js (Q3011087), the tool has not seen any development in years. Since it is also specifically about the use of DOI prefixes on Wikimedia sites, rather than DOI prefixes more generally, it is perhaps not the right tool to be associated with this property anyway, even if it were to function perfectly. --Daniel Mietchen (talk) 16:13, 19 May 2015 (UTC)[reply]

Prefix for journal

I added a prefix for a journal. I suppose that is not appropriate and should be deleted? — Finn Årup Nielsen (fnielsen) (talk) 17:39, 19 September 2017 (UTC)[reply]

@Fnielsen: This claim violated two constraints: the format constraint and the type constraint. I have broadened the type constraint to accept journals too, because it makes sense in the case of some DOI prefixes used by publishers for only one particular journal (for instance "10.1592" for Pharmacotherapy (Q7180800) according to http://api.crossref.org/members/311). I'm not sure about the format constraint - but I like the idea! − Pintoch (talk) 11:36, 8 December 2017 (UTC)[reply]

I expected to use this property for something like "journal has DOI prefix". But, because it's limited to one item ... I shouldn't do this? It seems like it would be a useful way to discover all journals registering a DOI on a prefix. --Jaireeodell (talk) 18:34, 22 February 2019 (UTC)[reply]

Duplicate format constraint

@Manu1400: why did you add a new format constraint? There is one already, what is wrong with it? − Pintoch (talk) 15:08, 3 November 2018 (UTC)[reply]

Alternate formatter URL for resolving DOI prefixes from multiple registries

Trilotat pointed out an issue where it appeared that a DOI prefix I entered for United States Geological Survey did not exist. The formatter URL on this property points to an API from CrossRef, which means that the resulting links will only resolve CrossRef DOIs. There are other DOI registries now, including DataCite.

It would be good to change this to handle a broader DOI lookup process for multiple registries. One alternative, would be to change the existing formatter URL statement from https://api.crossref.org/prefixes/$1 to https://doi.org/api/handles/$1. This would produce a different explicit REST API reference. The disadvantage to this would be any applications already built to use the current API response, which is quite different from doi.org.

Formatter URL itself seems like a little bit of an odd property that appears to have some variation in use against various HTTP-resolvable sources. A more ideal usage would be to point at something that is both human and machine usable, leveraging content negotiation at the URL to determine what response is needed. Human browsers will go to a web page with information on the identifier, and software could choose to get a more consumable response. In this case, the expedient of https://doi.org/$1 should do this with some content negotiation possibilities.

My proposal here is to change the formatter URL pointer for the DOI prefix property to https://doi.org/$1. Being new to WikiData, I'd like to know what this might screw up.

Not hearing anything for a little while, I went ahead and made the change. Another option to reduce complexity would be to simply use the DOI property in place of DOI prefix. Both a prefix DOI and a prefix with suffix DOI are valid digital object identifiers, and both will resolve at doi.org.

dx.doi.org is an earlier syntax that is no longer preferred

I'm reading from the DOI handbook the following:

DOIs may be structured to use the default public DOI proxy server https://doi.org (note that https is preferred over http, and that dx.doi.org, an earlier syntax, will remain fully supported but is no longer preferred)

Currently, the formatter URL for this property is https://dx.doi.org/$1 and http://dx.chinadoi.cn/$1. Shouldn't this just be https://doi.org/$1? What is dx.chinadoi.cn for? Mwtoews (talk) 22:14, 22 March 2022 (UTC)[reply]

querys

SELECT ?item ?itemLabel ?value

{

SELECT ?item ?value {

?item wdt:P1662 ?value

}

SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }

} Back ache (talk) 01:23, 28 February 2024 (UTC)[reply]

Single-use constraint is inaccurate

Notified participants of WikiProject property constraints

This property has gone a little stale, but I'd like to do some work with it. It would be useful to have a process that works with the major DOI registries DataCite and CrossRef to link their records for organizations and the associated DOI prefixes ("repositories") operated by those orgs to the Wikidata representations of the entities. We could then use the DOI prefixes as a jumping off point to other linked data here in Wikidata and beyond.

Before I start either start violating the heck out of the single-use constraint or adding thousands of exceptions, I'd like to get this property constraint removed. As I understand Wikidata norms, that needs at least a little bit of discussion and consensus here. So, if you are interested in this issue and use of the DOI prefix property, please weigh in.

To recap what I wrote above under the general discussion, many organizations who own and operate DOI prefixes have multiple "repositories" issued from DataCite, CrossRef, or both. The "provider" concept from those two platforms represents an organizational entity of some kind, often containing sufficient information (e.g., ROR identifier) to uniquely identify the organization and find its representation in Wikidata. If you take something like Purdue University, there are no DOI prefixes currently. You can look at the API response from DataCite for Purdue see that there are currently 12 DOI prefixes operated by the organization with ROR ID, 02dqehb95, giving us our hook to an existing WD entity. The appropriate way to record this information would be multiple DOI prefix claims on the Purdue item, preferably with a qualifier indicating that they are administered by DataCite. If this were in place, we could have SPARQL query routes to pull all kinds of interesting information together via WD as opposed to the cumbersome process of working with provider REST APIs from CrossRef, DataCite, or others.

While I wouldn't make it an actual requirement, I would advocate for incorporating a qualifier on DOI prefix claims indicating the operator (e.g., CrossRef, DataCite, or one of the other "registration agencies" in the DOI Foundation. (Also some work to be done there on documenting the DOI Foundation and its registration agency members. :-) Skybristol (talk) 23:20, 6 June 2024 (UTC)[reply]

Property talk:P1662

Contents

Documentation

Discussion

Wrong link

Prefix for journal

Duplicate format constraint

Alternate formatter URL for resolving DOI prefixes from multiple registries

dx.doi.org is an earlier syntax that is no longer preferred

querys

Single-use constraint is inaccurate

Navigation menu

Property talk:P1662

Documentation

Discussion

Wrong link

Prefix for journal

Duplicate format constraint

Alternate formatter URL for resolving DOI prefixes from multiple registries

dx.doi.org is an earlier syntax that is no longer preferred

querys

Single-use constraint is inaccurate

Navigation menu

Search