purl, vocabularies and ivoa.net

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Tue Sep 26 11:33:18 CEST 2017


Hi Nicolas,

On Mon, Sep 25, 2017 at 11:33:31AM +0200, nicolas moreau wrote:
> We need to identify the concepts in our vocabulary.  To do so we
> would like to use URIs as ID. The nice thing about doing that is we
> can associate a representation (ex a SKOS XML subset, an HTML page,
> a .txt file, ...) with an ID (in this case an URI), which can
> change over time, while the ID remains unchanged.
> 
> Since these URIs will be identifiers we want them to be permanent
> and unique. Then we need a namespace in ivoa.net where to define
> permanent URIs, to be used as identifiers.
> 
> Adding a 'purl' segment to a path rooted inwww.ivoa.net  could be
> used, sure, the problem is that www carries representation semantic
> with it, that is HTML. We don't want the identifiers to be coupled
> with representation details, such as HTML, or SKOS, rdf or
> whatever. The 'purl' subdomain doesn???t carry much semantic with
> it and seems a perfect abstract place (namespace) where to define
> permanent URIs to be used as identifiers, IDs.
> 
> So we propose:
> purl.ivoa.net/theory/ConceptName<http://purl.ivoa.net/theory/ConceptName>

The purl part I have no strong feelings about.  I think www.ivoa.net
would work just as well, and it's what Datalink and Registry use, but
if you're it's not a big deal.

What I *would* like to see consistent within the VO is the use for
fragment identifiers rather than paths.  For instance, a preview in
datalink is

http://www.ivoa.net/rdf/datalink/core#preview

Why?

(1) this resolves to an actual document where people can find out
what preview is; in this particular document, there's no anchor yet,
but it's trivial to make sure a browser actually goes to a document
part containing preview's description.

(2) it meshes nicely with content negotiations.  A client that wants
to read turtle or RDF-X can just set an Accept header and will
retrieve the vocabulary in its preferred format; the semantics of the
fragment remains the same, even though the actual operations to
retrieve the fragment are, of course, format-specific.

(3) it also fits nicely with the vocabulary URI mechanisms in RDFa
and friends (but ok, these would also work with paths).

It's also reasonably easy to manage such vocabularies, keeping a
historical record of previous versions of the vocabularies (Datalink
and RegTAP already contain tooling to do that).

        -- Markus


More information about the semantics mailing list