How to represent a bibliographic citekey in RDF

I’ve poured through specs for bibo, cito, fabio, dct, etc., and cannot find any RDF/OWL-ish means for representing a “citekey” as in BibText usage of that term.

For example, look at the entries for “Ontology Development 101: A Guide to Creating Your First Ontology” by Natasha Noy and Deborah McGuinness, such as:
https://www.bibsonomy.org/bibtex/2766b8314d938a9f54fb72ac03529692a/utahell

A commonly used citekey for their paper would be noy2001ontology

This is important in the practical side of curating bibliographies, e.g., where a team is managing multiple projects that have overlap and need to share a bibliography in common. Managing that metadata in a semantic graph is quite helpful, although I’ve never seen anyone support a citekey.

It’s not a problem to define in a couple lines of OWL, although rather than reinvent, I’d really prefer to use more accepted conventions if they exist?

Any suggestions for this?

You can use dc:identifier.

However, such keys are highly local. You should prefer DOI if available.

And if you have the need to capture the citation relation as a node, use the OCI URL format OpenCitations - COCI

Thank you Vladmir, and yes certainly the use of DOIs for persistent identifiers is important.

That’s not the question here, however. Within a team context, when people are working together to author papers, books, report, tutorials, open source, etc., and curating a shared bibliography over time, there will be use of citekeys (in addition to DOIs) as part of their team process. So much of the bibliographic process is well-defined and supported by popular vocabularies. However, so far I cannot find anything specific about citekey management – even though it is a concern for curating metadata.

Of course, yes the dc:identifier relation can be used as “catch-all” case, although it’s already becoming overloaded in practice for representing bibliographic metadata. For example, you mentioned DOIs … there’s also the need to represent open access URLs, which generally differ from DOIs. In that case, now we’re talking about 3 distinct meanings for the dc:identifier relation. Yes, that is possible in terms of KG representation; however, it’s a horrible practice in terms of supporting inference use cases downstream – which is what we must keep in mind. This dilution of semantics disrupts or complicates use of OWL closures, SHACL constraint rules, as well as adding more “tech debt” into workflows that feed KGE use cases. The KG does not like it :slight_smile: