Skip to content

CoIN: Composition of Identifier Names

Jump to bottom
timrdf edited this page Jul 5, 2012 · 16 revisions
csv2rdf4lod-automation is licensed under the [Apache License, Version 2.0](https://github.com/timrdf/csv2rdf4lod-automation/wiki/License)

The COIN vocabulary describes how to describe what properties of a resource constitute parts (segments) of a hierarchically built URI. (Which for all other purposes are supposed to be treated as opaque.) Data described using COIN can be used to control how to mint and/or check URIs of resources (ref).

csv2rdf4lod constructs URIs by concatenating "attribute-value" pairs to the end of a base URI, which is what CoIN is intended to describe. So, it'd be great to reconcile our design with theirs.

Details

Specifications / Overviews

Discussions

2012 Jun:

In general, the minting of hash-URIs/IRIs with CoIN may be a bit
underspecified. While I have defined a fragmentTemplate property for
that, I actually think that most of what I've used it for is possible
to do without it.

So, to describe the construction of a URI value of:

   "http://www.w3.org/ns/prov#hadDerivationByRemoval"

using CoIN, you just need a space like:

   @prefix coin: <http://purl.org/court/def/2009/coin#> .

   <http://www.w3.org/ns/prov/uri-space#> a coin:URISpace;
       coin:base "http://www.w3.org/ns/prov";
       coin:template [
               coin:uriTemplate "#{name}";
               coin:binding [ coin:variable "name"; coin:property coin:slug ]
           ] .

This, combined with data like:

   [] a rdf:Property; coin:slug "hadDerivationByRemoval" .

would produce the expected URI.

But I wonder if this really warrants use of CoIN? It may be easier to
skip the extra step of picking the fragment name from a property
(coin:slug, or any other property suitable for the fragment name), and
just mint the IRI mechanically?

Granted, this is a case where it might be desirable to declare some
more intricate transform rules. E.g. to enable one to pick the value
of an rdfs:label (possibly also matching on language), and transform
that using a newly defined coin:ToLowerLeadingCamelCase transform
rule. Is that what you'd prefer?

Do you use CoIN to mint URIs for things identified with bnodes, or to
verify URIs against existing descriptions? I primarily use it for the
latter, and for structured documentation of the construction
principles. Of course, I aim for CoIN to be usable also for minting
URIs during the initial creation of a resource description. I just
haven't yet worked a lot with that.

Glossary

See also

Clone this wiki locally