Re: Identifiers with context

Thanks Dave,
Yes, in general, I find DC(terms) problematic, and best to avoid.
It still carries too much heritage of strings.

In particular, both dct:creator and dct:subject currently say "a literal value that identifies the creator/subject may be provided.”.

That’s OK if you are in your own little world, but if you are ingesting from a number of sources, things can go very wrong.
And in the wild in the past, I found that dct:creator and dct:subject very often had string ranges (I’ve not looked much recently).

If you are publishing, your consumers will have to assume that the range is a string, when in fact you want them to know it is a URI.

Hugh

> On 23 Feb 2023, at 18:28, Dave Reynolds <dave.e.reynolds@gmail.com> wrote:
> 
> On 23/02/2023 15:37, Christoph, Pascal wrote:
>> Am 23.02.23 um 15:04 schrieb Mikael Pesonen:
>>> Hi, we are mapping non RDF data to RDF. There are entities that have
>>> identifying codes, for example 1.1, 1.2, 2.1  and external organization
>>> (lets name it "org1") is maintaining the codes.
>>> 
>>> Using predicate dcterms:identifier the most straightforward way would be
>>> to use literals:
>>> 
>>> :entity1 dcterms:identifier "1.1" .
>> "Comment: Recommended practice is to identify the resource by means of a string conforming to an identification system. Examples include International Standard Book Number (ISBN), Digital Object Identifier (DOI), and Uniform Resource Name (URN). Persistent identifiers should be provided as HTTP URIs." [1]
> 
> True but that link also states that the range of dcterms:identifier is rdfs:Literal.
> 
> So the implication would be to use:
> 
> :entity1 dcterms:identifier "https://www.our-company.com/ns/org1/1.1"
> 
> which is a bit unappealing, if conformant.
> 
> A third way I've seen used is to use typed literals:
> 
> :entity1 dcterms:identifier "1.1"^^<https://www.our-company.com/ns/org1/scheme>
> 
> Has the advantages or conforming to the range of dcterms:identifier, and allowing the lexical form and authority URI to be separated while still just using a simple literal. Disadvantage is that tool chains vary in how happy they are with custom typed literals.
> 
> Dave
>

Received on Thursday, 23 February 2023 18:55:21 UTC