Gabe Beged-Dov wrote: > > Models are Resources > ================== > > Many of the participants have indicated their desire for being able to > treat models as resources. I just wanted to point out what may be obvious > which is that each set operation returns a new model. Each of these result > models should also have their own URI. This falls under the issue of NoName > resources. The handling of new versions of models is not clear yet. 1. Often you want to say something about the state of affairs right now. Like "On what address does this person live?" or "How is the weather tight now?" This is things that change with time. 2. Maby you want to correct, reorganize or add to a description of something. I always visualize the model URI as a resource you could retrieve with a http GET request. The web page would show up as serialized RDF/xml. This URI is owned by the people with the power to decide over the content of the URL document. (And that fact could be described in some metadata.) The application should differ between models it owns and models it doesn't own. You could make a local copy of a model, but you have no right to change it. That would make the cached copy faulty. You could state your own version of things in your own model and you could comment on things in others models, using reification. Model versions -------------- It is up to the model owner to decied on the handling of new versions. In many cases, you would like to have a version number as part of the URI. Later versions would subclas/extend/override things in the previous version. That would be the case for core schemas used in applications, like core literal value types, logic representation, and many other things. But I wouldn't want to make it a whole new model for every change in a big database. As an example, http://rdf.cogsci.princeton.edu/wn16/ would not have to change to http://rdf.cogsci.princeton.edu/wn17/ if you changed the wording of a description in one of its entries. It's up to the application to have a current copy of a model. Problems with lack of model versions ------------------------------------ You can't make good comments of statements that change or disappear. A statement of a model could be made false if the content of the model changes. This should be expected in many cases. An RDF description service could state that a particular PICS server is to be trusted for giving accurate ratings of used automobile web auctions. The PICS server would be a model (the top one in a hierarchy of models), and that model could change from day to day. But the statements from the meta-service would still be valid. As another example: every web index and even, in the future, the RDF web pages indexed by the web index would be models. You can't continue changing the uri for every single change in any single other uri. But the lack of model versions would be a problem in cases where you say somehting like "everything in this model is true", and then a nasty error makes its way to the model. Other things to say about a model could be about its origin, its size, etc. I think that the problems with statements about models could be handled on a higher level, in RDF itself. You can never be sure to have the absolutly latest version of a model. You can only state what you believe to be true. Statements about the size, last modification date, and other things about a model should be updated by the application. Two applications (or RDF caches) could have conflicting data about the last modification date. This could be used to determine if an update is in place. But the real problem of the lack of versioning comes if you decide to use models as the base for naming triples. (to be continued... ;)