W3C home > Mailing lists > Public > public-lod@w3.org > April 2010

Re: CoIN: Composition of Identifier Names

From: Niklas Lindström <lindstream@gmail.com>
Date: Wed, 14 Apr 2010 13:14:11 +0200
Message-ID: <i2hcf8107641004140414v2a0d22efrac3d8a1fbf3f4b22@mail.gmail.com>
To: Richard Cyganiak <richard@cyganiak.de>
Cc: Linked Data community <public-lod@w3.org>
Hi Richard,

thanks a lot for the feedback!

Indeed, documentation for CoIN is too sparse right now. I guess I
cannot just give you my data structures and the algorithms will be
obvious.. ;) I will work on documenting the basic principles and
algorithm in an understandable way, as well as providing code samples
to try things out for real. For now, here's a dense summary (which
I've also included in the CoIN page [1]):

The basic mechanism for using a coin:CoinScheme is to match the RDF
properties of a given resource against "a full path" defined by that
scheme. Such a path is represented by nodes (usually bnodes) starting
from a coin:Base, linked with "coin:contains". Each such node
represents a step in the path, either just a (URI) segment (given in
"coin:segment"), or a "coin:component" which reference a property. For
the latter, there must be a value for the given resource, which is
then used to create the segment.

The values used to create these segments are either:

Literals, which are "translated" by e.g. lower-casing, url-encoding
*or* replacing diaretics with base characters (e.g. "ö"->"o") etc.;

Resource references. Principially these should not be used verbatim
(since they are full URI:s), but instead somehow be turned into a
token fitting for the URI scheme. With CoIN, this can be done by

* a token obtained via "coin:tokenFrom", translated as above, or
* a matching coin:Token (within a referenced coin:TokenSet) which
declares segment symbols for the possible resources (that is since
e.g. a segment for some dct:publisher must be under the URI-minters
control, but descriptions of that resource may be beyond control,
wherefore "coin:tokenFrom" won't be a reliable (deterministic)

There are also properties for restricting a (node in a) path to a
resource type ("coin:forType"). Apart from "coin:Base" paths, new
URI:s can also be minted from a "coin:Containment", where minted
segments are appended to an existing URI for a related resource
("coin:Containment" with either a "coin:baseRev" (e.g.
"dct:isVersionOf") or "coin:baseRel" (e.g. "dct:hasVersion")).

.. Regarding URI-templates (which are definitely an option), I'll
reply to that in my next mail (following Ed's reply).

Best regards,

[1]: <http://code.google.com/p/court/wiki/COIN>

2010/4/13 Richard Cyganiak <richard@cyganiak.de>:
> Niklas,
> On 13 Apr 2010, at 10:06, Niklas Lindström wrote:
>> I'd like to point you to a vocabulary I've made for describing how to
>> mint (or validate) URI:s from RDF properties of a resource: CoIN -
>> Composition of Identifier Names [1].
> Nice. Creating URIs from descriptions of resources is a recurrent problem,
> so it's great to see a proposal in this space!
> I had a look at the documentation and didn't quite manage to grasp how it
> works in detail. The documentation is mostly just a usage example, which is
> a nice start but doesn't quite do it for me. Looking at the N3 for
> rdfs:comments also didn't help much.
> I think that URI Templates [3] might be a handy companion syntax for CoIN
> and I wonder if they could be integrated into CoIN. I'm thinking more about
> the general curly-brace-syntax rather than the fancy details. So perhaps you
> could start with something like
> http://example.org/publ/{publisher}/{document}
> http://example.org/publ/{publisher}/{document}/rev/{date}
> http://example.org/profiles/{name}
> and then attach further information to those {foo} parts, e.g. a TokenSet
> and the represented property.
> Anyway, nice work.
> Best,
> Richard
> [3] http://bitworking.org/projects/URI-Templates/
Received on Wednesday, 14 April 2010 11:15:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:05 UTC