As I have said earlier, the PICS 1.1 label facility is not of interest
to the metadata community.
The PICS-ng specification (which is not, as far as I know, now
available publically, in that it is being discussed by the working
group) will allow strings, substructure, qualifiers, and repeatable
elements.
Further, there are 4 association models of PICS metadata and resources:
1. meta embedded in the resource header.
easy, requires no additional infrastructure, and readily
harvestable, but perhaps not the best model for efficiency
(bloated headers) and maintainability (keeping metadata
consistent as resources are mirrored or copied will be a problem).
2. resource embedded in a metadata wrapper.
a useful model for wrapping images, for example. same advantages
and disadvantages as #1
3. coupled metadata
metadata is tightly coupled to the resource, may travel with it, but
is not embedded and can be handled as an object in its own right
4. third party metadata
metadata is linked to the resource by reference only; may or may
not be created, maintained, distributed by the manager of the
resource itself. requires additional infrastructure (eg.
database management tools)
this is the model that third party rating providers (label
bureaus) will be based on, but it is also the model for
distributed resource cataloging that already predominates in the
library world.
Models 2,3, and 4 could be applied to non-html objects
stu
|