Glen, I am looking to extract meaningful content from certain types of submitted data, so if a GML or a Geotiff I will pull out geo-position and utilize the spatial index of the database to speed queries as I would like to add the OpenSearch capability to the registry.
It would be useful to mark certain documents as interesting and 'mine' information and effectively give a resource an official (ISO, Dublin Core) classification (tag), or potentially generate another metadata document. e.g. register a geotiff document, generate a GML document based on its (the image) internal metadata and register the GML document as well with a dependency (association) between the two. The GML document is easier to read, parse and format - but the tiff is the common document. Looking at the tags table in the database I am not sure it is currently possible to use this schema with a taxonomy in this manner as it is seems that a tag is repeated rather than being unique and associated to a user - artifact. Again, no criticism intended - I am working as fast as I can with the ORM model to see what is possible as I wouldn't want to be coding this with DAOs! The ORM approach is primarily useful for ease of coding / deployment, and certainly shouldn't be considered as good as raw SQL - however I don't think the ORM limitations will be evident in a registry use case. The use of 1st and 2nd level cache( hibernate, and ehcache) will be an immediate speed improvement for the registry, and the ability to delete the artifact and to have all the objects (tag, rating etc) cascade in one line is simple. thanks, Norman On Jan 4, 2008 10:50 AM, Glen Daniels <[EMAIL PROTECTED]> wrote: > Hi Sanjiva, Norman, all: > > Sanjiva Weerawarana wrote: > > Thanks for the detailed feedback and rationale. > > +1 > > > The registry is really designed to store *arbitrary* content .. as such > > there's really no special storage handling for any type of data. As Paul > > said in his reply its certainly possible to implement an ORMRegistry > > (and we'd definitely welcome such a contribution), but I don't quite get > > it. Do you expect to look at the media type of the resource being stored > > to figure out how to map the data into a certain object type and then > > use the ORM mapper to store that into the database? We currently don't > > "deserialize" any resource before we store it .. we treat it at a blob > > of bytes and drop it in. That of course comes at a cost- you can't query > > into structured resources, but it make the registry highly scalable to > > anything. > > Actually, some of what we're doing/planning with respect to > Axis2/Synapse repositories and WSDL data might be along the lines of > what Norman's looking for in terms of typing, but without the ORM - > basically a way to tag particular areas of the registry as containing > "interesting" stuff that wants to run through some kind of processing > (whether custom indexing, validation, etc) based on its type. That > custom processing could certainly be arbitrarily extended. > > I'd be curious to see some detailed scenarios for how Norman envisions > using this stuff.... > > --Glen > > > _______________________________________________ > Registry-dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/registry-dev > _______________________________________________ Registry-dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
