Re: Does anyone know about a lid: URI scheme proposal?

Hello!

I am sorry that I missed this message and could not answer earlier. I am 
happy that my scheme was noticed and I will gladly answer any further 
questions.

 > It looks to me like yet another attempt at a persistent identifier 
scheme.

The original intent was to use lid: as a sort of SPARQL compression, 
removing the need to write a query each time when you look for a 
resource with a particular (non-URI) identifier. With a particular 
resolver (such as the one of mine at https://data.is4.site/lid/ ), a 
very short URI can be written "by hand" and expanded to a link to a 
SPARQL endpoint (see 
https://data.is4.site/lid://dbpedia.org/rdfs:label/Earth@en for an 
example, or 
https://data.is4.site/lid://dbpedia.org/rdfs:label/Earth@en?_action=debug 
for the generated query).

Whether that constitutes a persistent identifier depends of many aspects 
‒ whether the endpoint actually stores persistent data, whether the 
property chain consists only of owl:InverseFunctionalProperty (implied 
at least), and whether a concrete literal (plain or with a 
datatype/language) or a range of literals (untyped or a language range) 
is used. Even the prefixes are somewhat volatile (the target's knowledge 
of a prefix can be used). Therefore, a URI in the form 
<lid://server/a:b/c> is as persistent as the server's knowledge of a:, 
the property a:b, and the particular entity identified by that property 
as "c", and, from a semantical point of view, it identifies anything in 
general that satisfies these conditions, broadly. In that sense, it 
serves only as a shortcut to the real entity ‒ when you are describing 
an external dataset in RDF, it is better to stick to its particular 
identifier scheme when possible, and in your own dataset, it would be 
better to use http: since lid: URIs are somewhat self-referential in 
that case.

That being said, throughout the process some (in my opinion) cool 
possibilities arose naturally from the syntax, when you omit the host. 
This allows you to universally identify literals, for example 
<lid:15@xsd:decimal>; you can "shorten" vocabularies, e.g. 
<lid:uri/$foaf:> (identifying any vocabulary that is associated with 
this prefix), and you can definitely use existing properties to form 
persistent identifiers (but not locators), such as 
<lid:schema:isbn/9780345339706> (or anything else that is not a URN 
namespace yet). Feel free to use these for RDF purposes. ;-)

Sincerely,
IS4.

Received on Thursday, 4 January 2024 03:37:39 UTC