[Debwebid-discuss] rdf coordination

[Iain R. Learmonth]

On Wed, Aug 12, 2015 at 10:33:15PM +0200, chrysn wrote:
> We might be using different terminology here, but in my understanding
> the minting process primarily means deciding on a URI for a thing (or
> assigning a meaning to a URI), which not even necessarily requires there
> to be a server backing that URL (as we want to be nice participants of
> the semantic web).

If the URIs are not dereferencable, they're useless as far as I'm concerned.
My plan for meta.debian.net was that the namespace would be carefully
managed and things would be returned via Python functions. This might be
RDF, this might be 303 redirects, this might be JSON or plain text
documents.

> I'll chat up rhonda on that topic too, afaik she's been having an eye on
> having cool URIs that don't change(TM) on the web frontend for some
> time.

This comes with the carefully managed namespace.

> Actually, we currently have two models that describe roughly the same
> things, for example [1] and [2]; I'd leave out the topic of verbs for
> this thread. We should make up our minds about canonical URIs for those
> things. Not that it'd be *essential* for using the data (when both state
> that their doap:homepage is [3], they can be smushed), but it'd make
> things easier.
> 
> I'd prefer a style that neither of the current approaches use, but is
> closer to the PTS version's name:
> 
> http://packages.debian.org/src:arandr#project

Not dereferenceable and depends on packages.debian.org not polluting that
namespace which cannot be guaranteed at present.

> It's as badly dependent on the transport technology as any other URL we
> could dereference (for what I might consider a design flaw in URI
> design), but the hostname is semantic, we can tell apart the page from
> the thing with the fragment identifier without *necessarily* going
> through a 303 to make sure the thing and its description don't smush.
> I'm not a big fan of having the URIs in a separate namespace from what
> we use for describing the things in regular life (which would apply to
> both rdf. and meta.) because we're talking about the things here,
> there's nothing meta about them. (In the Plato cave example, that would
> be like saying "shadow of chair" when talking about the chair).

This is vastly increases the namespaces that need to be covered. It's worth
mentioning that CPAN (which rdf.debian.net integrates with) has also opted
for a PURL-in-a-seperate-namespace approach.

> > If you can make the data available in UDD and provide queries for getting
> > these and work out what schemas to use, then I can integrate these into the
> > meta.debian.net URL minting service.
> 
> From the schema[4] I'd say that the information is already inside UDD.
> The metadata about the tags is not available, though.
> 
> [4] https://udd.debian.org/schema/udd.html
> 
> > Even better, if you can provide code that grabs the queries from UDD and
> > returns an rdflib graph with all the relevant information in it, then I can
> > just drop that in.
> 
> I'll have a look.
> 
> Summarising, the question I'd like feedback on in this thread is: What
> is the most suitable URI, for example, for "the arandr source package"?

Are you talking about the abstract concept of the source package, the files
that comprise it or the project that maintains the package? Are you talking
about a specific version of the package or a collection of all versions?

I am considering dropping ADMSSW and going with pure DOAP which may simplify
things, but this is still something that needs more thought (and I have
given it a lot so far).

Thanks,
Iain.

-- 
e: irl at fsfe.org            w: iain.learmonth.me
x: irl at jabber.fsfe.org     t: EPVPN 2105
c: 2M0STB                  g: IO87we
p: 1F72 607C 5FF2 CCD5 3F01 600D 56FF 9EA4 E984 6C49
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debwebid-discuss/attachments/20150812/ea2757c1/attachment.sig>