No plugin registered for `text/rdf+n3`

[sindikat]

I can't dereference URIs that start from "http://dbpedia.org/ontology/":

>>> g.parse('http://dbpedia.org/ontology/Person')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/rdflib/graph.py", line 1025, in parse
    parser = plugin.get(format, Parser)()
  File "/usr/local/lib/python2.7/dist-packages/rdflib/plugin.py", line 103, in get
    "No plugin registered for (%s, %s)" % (name, kind))
rdflib.plugin.PluginException: No plugin registered for (text/rdf+n3, <class 'rdflib.parser.Parser'>)

Is this DBPedia's problem (content-type text/rdf+n3?) or Graph.parse problem?

[ghost]

The discussion trail is long and muddy but it looks like dbpedia may have jumped the gun and gone off in the wrong direction, according to my reading of the latest posting about the status of the n3 media type registration, made to the appropriate w3 discussion list 1

ATM, courtesy of uholzer 2, RDFLib registers a "text/n3" media type 3 for parsing N3:

register(
    'text/n3', Parser,
    'rdflib.plugins.parsers.notation3', 'N3Parser')

Until it's officially resolved, here's a workaround you can use:

>>> import rdflib
>>> g = rdflib.Graph()
>>> from rdflib.plugin import register, Serializer, Parser
>>> register('text/rdf+n3', Parser, 'rdflib.plugins.parsers.notation3', 'N3Parser')
>>> g.parse('http://dbpedia.org/ontology/Person')
<Graph identifier=N55f0fa25f6624ed6a4b808596b6728e5 (<class 'rdflib.graph.Graph'>)>
>>> 

I have to say, on a casual inspection, I'd be inclined simply to add "text/rdf+n3" to RDFLib's registrations but only after quite a careful reading of the relevant posts on the w3 mailing list in order to understand fully the reasons why the proposed media types haven't yet been successfully registered.

HTH.

[sindikat]

Thank you for a workaround.

Redland's rapper recognizes text/rdf+n3 (see: http://answers.semanticweb.com/answer_link/24795/). Does that necessarily mean that RDFLib should too?

[gromgull]

Actually - the chance of any bugs occurring if we DO add text/rdf+n3 seems slim - I would just add it and reduce the load on the implementor .

[ghost]

TIL that text/n3 is the official IANA media type for Notation3 and has been for a couple of years:

http://www.iana.org/assignments/media-types/text/n3

The W3C has a handy, actively-maintained table of media types, details and registration status:

http://www.w3.org/2002/06/registering-mediatype

Independently of the resolution of this particular issue, I'll add docstrings to the media type registrations in plugins.py, each carrying the relevant IANA URL for the supported media type.

There's an attendant documentation issue: either alerting users to possible bugs when parsing alternative media types or illustrating how to register an alternative media type and choose an appropriate parser.

These are the iana discussion sub-threads pertaining to the text/n3 registration. These I have read but not yet had time to investigate in more detail and which allude to an earlier discussion of problems with the "rdf+" bit of "text/rdf+n3" --- which in turn hints at a rationale for the eventual registration of "text/n3":

request for review Feb 2011 https://www.ietf.org/mail-archive/web/ietf-types/current/msg01176.html

discussion of status Jan 2011 https://www.ietf.org/mail-archive/web/ietf-types/current/msg01158.html

And a 2008 W3 document on the nitty gritty of rdf media types: http://www.w3.org/2008/01/rdf-media-types

(Mainly for reference)

[sindikat]

either alerting users to possible bugs when parsing alternative media types or illustrating how to register an alternative media type and choose an appropriate parser.

Why is that an either-or problem?

[ghost]

I'm glad that your experience of FOSS project documentation is more positive than mine.

[niklasl]

It may be that "rdf+n3" would have been incorrect because Notation 3 is a superset of RDF – i.e. not all N3 data is valid RDF data?

[uholzer]

If you look at other examples, say application/xml vs. application/soap+xml it seems that the left hand of the + indicates a (semantic) restriction on the document format on the right hand side. I.e. soap+xml is a strict subset of xml. rdf+n3 would be an N3 document that encodes RDF only. Therefore it could not contain any formulas. This explanation implies that rdf+n3 is the same as trutle. So, text/turtle is the content-type DBPedia should be using.

We could register the turtle parser for text/rdf+n3. Or even better, file a bug report against DBPedia so they fix their content-type? I think it is too soon in the history of the semantic web to work around mistakes of content publishers in core libraries.

I vote for properly documenting how to register parsers for media types manually.

Possible report of this problem in the DBPedia bugtracker: http://sourceforge.net/p/dbpedia/tracker/13/

[nicholascar]

This issue has had no comments for 6+ years so I'm closing in an effort to tidy up Issues generally.

The substantive point - handling of text/rdf+n3 has gone away since many years have now passed with an official Media Type of text/n3 being widely known.