purl, vocabularies and ivoa.net

[nicolas moreau]

Hi Markus,

We have no objection against the use of fragment identifiers. However we 
think is it necessary to keep the  purl subdomain.
It will be easier then to configure a redirection to the page were the 
vocabularies are actually stored.

With the use of a fragment identifier, a typical identifier for a 
concept would be :

http://purl.ivoa.net/theory/vocabulary#ConceptName


best regards



Le 26/09/2017 à 11:33, Markus Demleitner a écrit :
> 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


-- 
-------------------------------------------------------------------------------------------------------------------
Nicolas Moreau,  Observatoire de Paris-Meudon-Nancay
LERMA 01 45 07 79 76 mail:nicolas.moreau at obspm.fr
-------------------------------------------------------------------------------------------------------------------