 |
 |
On Tue, 9 Sep 2003, Weibel,Stu wrote: ... > Roughly speaking, a metadata store is a collection of assertions that relate > entities, properties and values. We partition those assertions in > particular ways for database performance reasons, for functional reasons, > for administrative reasons, for economic reasons. Yes... for example: Milage is different for all of us, but most people would prefer to query retrieval systems delivering predictable result sets. That is, we want a title and a URL as a minimum if we query, for instance a web search engine. From that we can construct a list of HTML anchors. If each hit is accompanied by a description and subjects we can give more to users to evaluate which of the resources presented are relevant for him or her. If we get subject terms we may make them clickable, such that a new search is initiated on these terms. > It seems rather important to be able to aggregate a set of assertions in a > particular way, even though we may want to get query results that span many > records. Well, to me it is sort of one of the things we've been aiming at for years. Isn't the CORE about this; the definition of a predictable set of properties of resources useful for simple resource discovery? > Where is the abstract representation of this aggregation, or is it > needed at all? The aggregation of properties that is needed in a given situation depend on the nature of the resource, functional requirements of your service and whatever. As a rule, the CORE is seldome enough. What is the difference between a an abstract representation of an aggregation of properties used to form a "record" and XML or RDF schemas? I don't think that beast would be a RDF schema, since we don't wont that animal to redefine the semantics of the members of the aggregation. It could be written in RDF though. It could assert that the a given aggregation has semantics X1, X2, ... Xn as members. You I suppose you could specify the same thing using an XML schema or a DTD, though. Sigge