Issue with classes inheriting from Resource

[dokamo]

When creating a class that inherits from Resource, any resource generated from inside the subclass is initialized as the subclass (not as Resource).

Exemple:

from rdflib import *
from rdflib.resource import Resource
from rdflib.namespace import RDF, FOAF

class Person( Resource ):

    def __init__(self, graph, subject):
        super(Person, self).__init__(graph, subject)
        self.add( RDF.type, FOAF.Person )

    def interest(self):
        return self.value( FOAF.interest ) # that's the point

g = Graph()
mike = Person( g, URIRef('http://example.com/mike' ) )
any = Resource( g, URIRef('http://example.com/any' ) )
mike.add( FOAF.interest, any)
interest = mike.interest() 
print g.serialize(format='turtle')

Outputs:

...
@prefix ns1: <http://xmlns.com/foaf/0.1/> .
<http://example.com/mike> a ns1:Person ;
    ns1:interest <http://example.com/any> .
<http://example.com/any> a ns1:Person .     <---- Who said that!?

Edit: rdflib version is 4.2.1

Cheers,
Marc

[niklasl]

Your example said that, in Person.__init__. :) This is by design, to make the subclass work for all wrapped graph methods, in cases where a Resource subclass adds additional features that you want available on all returned resources (as illustrated in the doctest example linked above).

That evidently clashes with your usage, which ties subclasses to specific values for rdf:type. The solution is for you to override the _new method in your subclass:

def _new(self, subject):
    return Resource(self._graph, subject)

... I leave selecting specific subclass based on rdf:type (and auto-registering this) as an exercise for the interested... ;)

[dokamo]

Yes, you are right! Once examined with a cool head, is much better like this. :)
My fault not checking the type before going crazy, as the __str__ method said it was a Resource (I'll never trust you again, __str__! ;) )

Thank you for suggestions. Good job!

Cheers,
Marc

PS: Just a rough tentative about selecting specific subclass based on rdf:type, for the interested.

class Item(Resource):

    def __init__(self, graph, subject):

        self._casting = [
            (FOAF.Person, Person),
            (FOAF.Organization, Organization)
        ]
        Resource.__init__(self, graph, subject)
        if 0 == sum(1 for _ in self._graph[subject]):
            self.set_type()

    def set_type(self):

        for type,clss in self._casting:
            if clss == self.__class__:
                self.add(RDF.type, type) 

    def _new(self,subject):

        for type,clss in self._casting:
            if type in self._graph.objects(subject, RDF.type):
                return clss(self._graph, subject)
        return Item(self._graph, subject)

[white-gecko]

You issue with __str__ is also caused be the string written in the __str__ implementation of Resource.

[white-gecko]

I also just stumbled on the same same issue, as I have implemented a subclass of Resource that sets a type.

I'm not sure if the current behavior is that strait forward and easy to understand. Wouldn't it be better to let use cases that what their implementation to return instances of their subclass overwrite the _new method?