Print

Print


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 [1].

Tim

[1] https://www.wikidata.org/wiki/Property:P244#P1921


--
Tim A. Thompson
Discovery Metadata Librarian
Yale University Library


On 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:
>
>
>
> https://www.wikidata.org/wiki/Property:P244
>
>
>
> 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:
>
>
>
> https://www.wikidata.org/wiki/Q963044#P434
>
>
>
> Jeff
>
>
>
> *From: *Bibliographic Framework Transition Initiative Forum <
> [log in to unmask]> on behalf of Simeon Warner <
> [log in to unmask]>
> *Reply-To: *Bibliographic Framework Transition Initiative Forum <
> [log in to unmask]>
> *Date: *Tuesday, February 19, 2019 at 10:24 AM
> *To: *"[log in to unmask]" <[log in to unmask]>
> *Subject: *Re: [BIBFRAME] When a bf:Identifier is a URI
>
>
>
> 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
> identifiers"
>
> Cheers,
> Simeon
>
>
> 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 .
> > ) [1].
> >
> > 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 .
> >
> > [1]
> https://github.com/dcmi/usage/blob/master/minutes/2018/2018-11-20.dcub-decisions.md
> >
> > Best,
> >
> > Lars
> >
>
>