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
|