Sergey Melnik wrote: > > But: personally I like your proposal and I'd change Triple into > Statement and RDFModel into Model, if nobody has objections. > > RDF IG, are these names specific enough: Resource, Literal, Statement, > Model?? Pro/contra votes? I experimented a bit with names in my RDF schema editor: http://paranormal.o.se/perl/proj/rdf/schema_editor/ I soon changed the names to nodes and arcs, like: get_nodes_of_type( $type ) get_node_by_uri( $uri ) arc_exist( $uri ) etc... The reason is that the names is shorter, they are unambigous, and they help me to visualize the graphs while programming. I have some vested intrest in the solution I settled for in my prototype. I would not hesitate to use the Perl way of doing things, if that differed from the Java way. I would prefer practical experience of what is desired, rather than the minimal implementation. The API would not have to be identical between the java platform and the perl platform. But it would help if there was a common interpretation of the RDF spec, and how certain problems should be handled. I wonder how much you looked at the perl RDF API... is_instance_of > Thus, a SchemaModel (which will extend the VirtualModel), could be asked > for something like > > boolean isProperty = sm.find(r, RDF.type, RDF.Property).size() > 0; That would not work. A resource could be an instance of property without having the type Property. Take a look at this, for example: http://paranormal.o.se/perl/proj/rdf/schema_editor/devel/latest/rdf.cgi?state=inventory&uri=rdfs%3AConstraintProperty Ok. I see that you are doing something about this: // special case: predicate might be rdfs:subPropertyOf something But this special case should only be handled in the schema layer. My code is not commented, but is_instance_of() can be seen here: http://paranormal.o.se/perl/proj/rdf/schema_editor/devel/latest/RDF/Schema/Resource.pm And your isProperty() would be defined as: sub is_Property { my( $self ) = @_; return $self->is_instance_of( $self->model->rdfs('Property')->uri ); } As a comment: I am using the URI strings rather than the objects in every comparsion. One object in the program can not be certain if another object has retrieved the resource. You could think that if a URI is turned into an object, it should be registred so that all references would be to the same object if it has the same URI. You could also think that the object for RDFS:Property could be a static method, rather than being derived from the resource object. But I was thinking of the case there the program has multipple sources. In the DBI, all resources has an internal id. The object could be created in the schema layer, but it is ultimatly done by initializations methods in the source level. If there were multipple sources, the particular object would be a diffrent variable if it would originate from a diffrent source. ... Or would it? Maby I could change this. The cache should be located in the simple layer. The reason for "$self->model->rdfs('Property')" is that I am refering to an object. This object has to be created if it hasn't been retrieved yet. It would have to be retrieved from the source. This source (the database connection) is specified in the creation of the model. A pointer to that model is given in the creation of the resource object. This DB connection is used in the creation of the 'Property' object. I had to specify the source in one way or another. Do you have another suggestion for how the rdfs method/class should know what source to use for the creation of the object? My thought is that I maby should have a global cache taht would be source independent, and that could make the decission of what source to use. (You know: In perl, you can invent the way you want to build your programs. There is no restrictions...)