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
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
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