doi: and isbn: are both URN schemes, as far as I know.
Thanks, Jeff--I was just about to point to the Wikidata approach as well. Isolating the uniquely identifying component from the IRI allows for greater flexibility and supports persistence: a formatter URL can be supplied (and potentially changed when needed) to dereference the identifier as an IRI and potentially include that in serialized output .Tim https://www.wikidata.org/wiki/Property:P244#P1921--
Tim A. Thompson
Discovery Metadata Librarian
Yale University LibraryOn Tue, Feb 19, 2019 at 10:39 AM Young,Jeff (OR) <[log in to unmask]> wrote:
I like how Wikidata deals with this in their RDF. Each identifier scheme gets its own property, which can then be described in various ways. For example:
When you go to use that property as an external ID on items, which allows you to elaborate on that specific identifier using qualifiers, such as here:
I agree with Lars on both counts. An unquoted URI in RDF does not stand
for the identifier, it stands for the resource. Thus, ugly as it is,
there is no option except using a literal. One might paraphrase:
"The first rule of identifier club is that there is no way to talk about
On 2/19/19 5:32 AM, Svensson, Lars wrote:
> On Tuesday, February 19, 2019 9:49 AM, Adrian Pohl wrote:
>> On 19.02.19 04:03, Dan Scott wrote:
>>> In a linked data context, I think that forcing a URI to be
>>> represented as a literal (with a blank node as a bonus), instead of as
>>> the URI it is, is an anti-pattern.
>> I agree, but as I pointed out in the last email I also think that it is
>> bad practice to use an URI when you are talking _about_ the URI (like it
>> is bad practice to not add quotations when you are talking about a word
>> in a written sentence).
> I tend to agree with Adrian here: We're talking about the identifier as a sequence of characters.
>> But there is a third option, we should definitely consider: In my
>> opinion the best approach is to only use non-URI identifiers in a
>> bf:identifiedBy statement so that the question does not come up. In the
>> case that you have different URIs denoting the same resource it probably
>> is best practice to use schema:sameAs or something similar to state that
>> those URIs refer to the same thing.
> Here I tend to disagree with Adrian: We should not limit ourselves to non-URI identifiers.
> I'm also not quite happy with the use of schema:URL (what if we use IRIs?). My preferred pattern would be to use dct:type to say what kind of identifier it is and have a set of skos:Concepts to represent the identifier types. (I know, the definition of dct:type says that the rdfs:range is rdfs:Class, but I _think_ that the DCMI Usage Board currently is working on relaxing that to
> dct:type a rdf:Property ;
> schema:rangeIncludes rdfs:Class .
> ) .
> That way we'd get:
> @prefix bf: <http://id.loc.gov/ontologies/bibframe/> .
> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
> @prefix dct: <http://purl.org/dc/terms/> .
> @prefix skos: <http://www.w3.org/2004/02/skos/core#> .
> <http://example.org/2335409#Work> a bf:Text, bf:Work ;
> bf:identifiedBy [ a bf:Identifier ;
> dct:type bf:URI ;
> rdf:value "http://worldcat.org/entity/work/id/638612"
> ] .
> bf:URI a skos:Concept .
>  https://github.com/dcmi/usage/blob/master/minutes/2018/2018-11-20.dcub-decisions.md