Hi Steve, Great, thanks for taking a look.
I agree that syntactic validation would be best. This would also help to avoid various chicken/egg problems, while still ensuring that the "subject" is scoped within this object (so contradictory statements elsewhere in the repository are still not possible). Currently, RELSExtValidator also checks whether the predicate is in one of the fedora-reserved namespaces, and that would be a good sanity check as well. This is also to avoid contradictory statements, since as you know, some of those that get indexed in the triplestore (those in the fedora-model and fedora-view namespaces) are derived from elsewhere in the FOXML. Note that although RELSExtValidator also prevents DC statements from being made (since what's in DC is derived as a set of statements about the object), this restriction shouldn't be necessary for RELS-INT. - Chris On Thu, Jan 22, 2009 at 3:33 PM, Steve Bayliss <[email protected]> wrote: > Hi Chris > > Thanks for your reply on this, I'll take a look at our existing code and see > what it will take. > > Currently we've not implemented any validation - and I can see this could be > an issue. > > I'd expect the same validation as RELS-EXT with regard to "depth" - ie only > direct relationships from datastreams to literals or URIs, but as far as the > subject of the relationship goes, that might be more difficult - especially > if datastreams are added and deleted: to implement the same kind of > validation as RELS-EXT would in theory mean validating RELS-INT whenever > datastreams are added and deleted. > > Do you think it would instead be acceptable just to do a "syntactic" > validation of the subject, eg > > some:pid/datastream > > where "datastream" is not (necessarily) an existing datastream, but is a > valid name for a datastream? > > We could of course check that some:pid is the same as the object in which > the RELS-INT appears. > > Steve ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
