- From: Sergey Melnik <melnik@DB.Stanford.EDU>
- Date: Mon, 13 Dec 1999 19:20:40 -0800
- To: Jonas Liljegren <jonas@paranormal.o.se>
- CC: RDF Intrest Group <www-rdf-interest@w3.org>
Jonas Liljegren wrote: > 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... In order to avoid a combinatorial explosion of the number of methods to implement by an RDF model, the API [1] contains a single generic access method find(s, p, o). If a parameter is left null, it matches everything. Specific methods like the ones above can be provided as static methods on top of the generic one. > > 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: Sure it could. But if there is a "ground fact" (s, p, o) in the schema model, the information (p, RDF.type, RDF.Property) can be easily derived. A "virtual model" can deliver triples not explicitly contained as facts. > Ok. I see that you are doing something about this: > // special case: predicate might be rdfs:subPropertyOf something Oops. Sorry, VirtualModelImpl.java is just mistakingly in the source distribution, it would not compile. This code would go into org.w3c.rdf.schema.impl.SchemaModelImpl. > But this special case should only be handled in the schema layer. True. > 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. This is desirable, but can hardly be enforced. You cannot prevent other third-party modules create instances of Resources. > You could also think that the object for RDFS:Property > could be a static method, rather than being derived from the resource > object. This is how it is implemented right now. RDFS.Property is a static variable. > 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. Correct. This was my original motivation behind introducing CRCs and, later, MD5 digests *and* requiring hashCode() -- a standard Java method implemented by every object -- to be based on the digest of the RDF node. The API also suggests that resources, literals, triples and models implement the Digestable interface. Thus, the nodes can be easily compared using their digests. A database application could for example retrieve only 128-bit MD5 hashes of literals (that can be as large as many MB) and compare them with other implementations of literals etc. > 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? Currently, RDFS resources are static variables. Using hashes allows mixing different implementations. > 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...) Again, I think different implementations and instances of the same resources can peacefully coexist in the same runtime environment. It is hard to prevent it given the design autonomy of individual developers. Sergey
Received on Tuesday, 14 December 1999 09:49:51 UTC