Your Turtle example is actually not syntactically valid, because Turtle is a "triples-only" format - so you won't find any tool that can parse/process that. The notion of weighted edges takes you outside the realm of the RDF standards, which is why you won't find many RDF tools offering explicit support for it.
However, you might be able to achieve what you want with most standard RDF tools if you're willing to slightly modify your data. I'll use RDF4J in this example.
To model edge weights, you can use the notion of "named graphs" - which in RDF4J is supported via the use of quads instead of triples. Using, for example, N-Quads as the format (very similar to Turtle/N-Triples, but allows for the extra named graph info needed), your example could look like this:
<http://dbpedia.org/resource/Category:Futurama> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2004/02/skos/core#Concept> <http://example.org/weight-8-0> .
<http://example.org/weight-8-0> rdfs:label 8.0 .
As you can see the idea is to define a new named graph (identified by
http://example.org/weight-8-0 in this example), and use that as the graph identifier for the statement you want to assign a weight to. The second statement is merely there to link an actual weight value to the identifier.
Of course, this approach does mean that you introduce a new RDF statement for every single possible weight value, so it's only really workable if there is some manageable number of possible values. Then again you are talking about 5 million statements in your dataset, so in the worst possible case you would double that, to 10 million statements, which is still easily manageable by most RDF databases.
Using this approach, Eclipse RDF4J (formerly known as OpenRDF Sesame) is a good framework to use. It's open source (Eclipse Distribution License), platform-independent (Java), has support for Turtle as well as N-Quads and TriG syntaxes (and most other RDF syntax formats), and full SPARQL 1.1 support as well as a comprehensive Java API. Its own databases can handle up to the order of 100M statements, and if you want to scale beyond that, there are plenty of scalable RDF database vendors that are fully RDF4J-compatible (so you can switch database implementation without having to change your code).