[Debwebid-discuss] rdf coordination

[Iain R. Learmonth]

Hi,

On Thu, Aug 13, 2015 at 07:10:14PM +0200, chrysn wrote:
> > For some services it may be possible to provide a SPARQL endpoint. It got
> > out of hand extremely quickly when I added triples to represent package
> > inter-dependencies (over 40GB of rdflib graph followed by a crash).
> 
> I've got to admit that I have zero experience running SPARQL endpoints.
> It sounds like the order of magnitude of data dbpedia is offering
> (judging from [1], provided your 40GB are uncompressed, but then again I
> have no idea what hardware they are running on.

SPARQL is slow. Unless you have the resources to provide a SPARQL endpoint
and a good reason to, it's probably not something to do for now.

> > rdf.debian.net links to CPAN and PyPI currently. See:
> > 
> >   http://rdf.debian.net/project/librdf-linkeddata-perl.html
> 
> Its data source seems to be semantic-debian/perl.ttl. Where was that
> deduced from?

The update-perl.py script uses a PerlPackages.bz2 and the CPAN package list
to generate the triples. In the meta.d.n version of this, the package
mapping will be stored in UDD and the triples generated dynamically, also
with PyPI (using the code in update-pypi.py) - PyPI could really do with
better URIs.

> Could you give a rough overview of what that would do or how it would be
> used? The only match I've found for RDF and XMPP pubsub was BBC
> programme subscriptions, and the profiles attached to XMPP accounts.

No idea yet. It seems like they're complimentary technologies though and
there could be something fun to do.

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: 473 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debwebid-discuss/attachments/20150813/6e6694e5/attachment.sig>