Comments on: Improving VALET - part 1 http://ptsefton.com/2008/07/30/improving-valet-part-1.htm "As noble thoughts the inward being grace, So noble whiskers dignify the face." Tue, 06 Jan 2009 23:25:08 +0000 http://wordpress.org/?v=2.3.1 By: ptsefton http://ptsefton.com/2008/07/30/improving-valet-part-1.htm#comment-1951 ptsefton Fri, 01 Aug 2008 01:12:10 +0000 http://ptsefton.com/2008/07/30/improving-valet-part-1.htm#comment-1951 @joe - good idea. Something along the lines of this, maybe: http://tinyurl.com/5uqtam @joe - good idea.

Something along the lines of this, maybe:

http://tinyurl.com/5uqtam

]]> By: Joe Liversedge http://ptsefton.com/2008/07/30/improving-valet-part-1.htm#comment-1944 Joe Liversedge Wed, 30 Jul 2008 10:00:19 +0000 http://ptsefton.com/2008/07/30/improving-valet-part-1.htm#comment-1944 Have you considered using something triple-friendly as an option for storing the raw VALET information? It would give you some opportunity for coordination across Fedora installations and wouldn't be a costly compromise over the strict attribute-value model. It would give you all the benefits of standardization without all the hassle. Consider, for instance, that the institutional Web page of a submitter might be kept for one reason or another. A 'hostname' field would get you pretty far, but making the relation to the URI 'http://xmlns.com/foaf/0.1/workInfoHomepage' would let Vicki indicate that she means the kind of 'hostname' as Tim. Since you'll be creating the Fedora object, there's an immediate opportunity to inject this into the RELS-EXT datastream, thus exposing it to the world, really, through the Fedora ResourceIndex. In doing so, we may be able to define the kind of values that have historically not been terrifically universal in the wide-open, schema-dependent world of VITAL/Fedora where unique or domain-specific information may live just out-of-reach of existing XML schemas. This would also let institutions have access to things like a cataloged DOI or ISSN without having to pull it out somewhat blindly from the descriptive metadata. The payoff would be that any niche type of metadata can be exposed through the triplestore as a relation to the Fedora data object. This metadata is available to VITAL's Velocity templates and can be integrated into the display alongside what's considered the 'canonical' DublinCore/MARCXML/MODS descriptive metadata and would be, again, a relatively low-cost prospect with the nice side-effect of contributing to the still-nacent semantic content of the world. Have you considered using something triple-friendly as an option for storing the raw VALET information? It would give you some opportunity for coordination across Fedora installations and wouldn’t be a costly compromise over the strict attribute-value model. It would give you all the benefits of standardization without all the hassle.

Consider, for instance, that the institutional Web page of a submitter might be kept for one reason or another. A ‘hostname’ field would get you pretty far, but making the relation to the URI ‘http://xmlns.com/foaf/0.1/workInfoHomepage’ would let Vicki indicate that she means the kind of ‘hostname’ as Tim.

Since you’ll be creating the Fedora object, there’s an immediate opportunity to inject this into the RELS-EXT datastream, thus exposing it to the world, really, through the Fedora ResourceIndex. In doing so, we may be able to define the kind of values that have historically not been terrifically universal in the wide-open, schema-dependent world of VITAL/Fedora where unique or domain-specific information may live just out-of-reach of existing XML schemas. This would also let institutions have access to things like a cataloged DOI or ISSN without having to pull it out somewhat blindly from the descriptive metadata.

The payoff would be that any niche type of metadata can be exposed through the triplestore as a relation to the Fedora data object. This metadata is available to VITAL’s Velocity templates and can be integrated into the display alongside what’s considered the ‘canonical’ DublinCore/MARCXML/MODS descriptive metadata and would be, again, a relatively low-cost prospect with the nice side-effect of contributing to the still-nacent semantic content of the world.

]]>