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:24:05 +0200
Message-ID: <k2qcf8107641004140424o2f40ef68lc4acc3e6fd48465b@mail.gmail.com>
To: Ed Summers <ehs@pobox.com>, Richard Cyganiak <richard@cyganiak.de>
Cc: Linked Data community <public-lod@w3.org>
Richard, Ed,

URI-templates are certainly valuable, and quite promising in
conjunction with CoIN.

I did briefly consider them before, and I think it's worth investigating more.

I wonder if you think it would be worth supporting them verbatim, or
if CoIN schemes should be considered a structured ("parsed")
description of the same mechanism? Since URI-templates have some quite
refined features, and is still a draft, I initially designed CoIN more
as a structured subset.

I did consider several alternatives to making a vocabulary as well.
Initially I had programmatic URI minting (which I suppose is the
common case today). Then I tried making it more
implementation-independent, initially with domain-specific SPARQL. It
got a bit convoluted and hard to overview, so I started extracting the
domain-specifics (which properties to use for certain types etc.) into
a separate data structure, to make it declarative and completely
data-driven. I looked at combining sioc:Container (with segments
provided with sioc:id) and owl:Restrictions, and even took a stab at
using SPIN for those parts.

It all got very complicated. So I designed CoIN as a specific
vocabulary, It's nested structure was initially based on RDF Lists
("segment", some:property), which I made less convoluted with the
current use of nested "coin:contains" expressions.

But this level of complexity may still be a bit high.

I took a stab at how a "CoinTemplate" would look like, if CoIN is to
support them verbatim. Something like (assuming a base URI is defined
in the parent CoinScheme):

    [] a coin:CoinTemplate;
        coin:scheme <> ;
        coin:uriTemplate "/publ/{publisher}/{label}";
        coin:variable [
                coin:var "publisher";
                coin:component dct:publisher;
                coin:useTokenSet <./tokens/publishers>;
            ], [
                coin:var "label"; coin:component dct:alternative
            ] .

Using this structure is certainly more flat, since the path components
aren't nested to get the order, but encoded in the uriTemplate. And
there is no need to tinker with the hard-coded segments as only the
variable parts (using "coin:component") are expressed in the RDF.

The downside of the URI-template approach, as opposed to the current
CoIN mechanism, is that with the current approach the structure can be
analyzed to see if there'll be any collisions, e.g. between "hard
coded" segment values and values obtained via coin:useTokenSet (who
may, for better or worse, occupy the same segment position). This
since the entire URI structure is encoded as RDF.

(There are other possibilities in having this structure explicit, say
for creating URI dispatchers or something like that. Although that
specific case implies using CoIN data for parsing..)

Using CoinTemplate:s like above also becomes more verbose (nearly
doubling the amount of data required to describe our current scheme
(see links below)). But perhaps it'll be more approachable..

In any case, I'd prefer not to express the uriTemplate as an RDF list
(again). So *if* it would be desirable to express the entire "parsed"
structure, but with more flexibility than the current "segment and
separator" orientation, CoIN could be redesigned to strike a
middle-ground between it's current form and the flat uriTemplate-based
one above. Mainly meaning I could skip "coin:separator" and
"coin:segment" in favour of a chain of "coin:contains" with properties
like "coin:prepend", "coin:append" for literal chunks to concatenate
with values from components.

Of course I can simply include the CoinTemplate terms exemplified
above in the vocabulary, so users can pick and choose. But since
that'd also complicate things for implementors, I'll do some more
evaluation of the options first.

(For reference, you can find our specific use here:
, using the token sets:
    <http://rinfo.lagrummet.se/sys/uri/org.rdf> and

.. But you should convert at least the scheme.rdf into N3 lest your
heads might explode. ;) Also, the domain-specific vocabulary ("rpubl")
are all swedish terms, so I'll suspect the details will be illegible
to everyone not understanding that..)

Again, thanks for the feedback! I will definitely think these options through.

Best regards,

On Tue, Apr 13, 2010 at 11:16 PM, Ed Summers <ehs@pobox.com> wrote:
> 2010/4/13 Richard Cyganiak <richard@cyganiak.de>:
>> 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}
> I second the idea of exploring the use of URI Templates for
> documenting how to construct a URL from other data. I'm not sure if
> it's part of the latest URI Templates draft [1], but OpenSearch allows
> parameter names to be defined with namespaces [2]. For example:
>  <?xml version="1.0" encoding="UTF-8"?>
>  <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"
> xmlns:geo="http://a9.com/-/opensearch/extensions/geo/1.0/">
>   <Url type="application/vnd.google-earth.kml+xml"
>       template="http://example.com/?q={searchTerms}&pw={startPage?}&bbox={geo:box?}&format=kml"/
> </OpenSearchDescription>
> Note, the use of the geo namespace and the geo:box parameter name? So
> you could imagine a URL template that referenced names from an RDF
> vocabulary:
> <Url type="application/rdf+xml"
> template="http://example.com/user/{foaf:mbox_sha1sum}" />
> OpenSearch was an incubator for the ideas that led to the URI
> Templates draft, and is built into many modern web browsers (IE,
> Firefox, Chrome).
> //Ed
> [1] http://tools.ietf.org/html/draft-gregorio-uritemplate-04
> [2] http://www.opensearch.org/Specifications/OpenSearch/1.1#Parameter_names
Received on Wednesday, 14 April 2010 11:25:06 UTC

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