I think this raises some interesting issues, probably for wider discussion.
At the moment the definition of what triples are generated is specified in code (eg fedora.server.resourceIndex.FedoraObjectTripleGenerator_3_0), some are specified in RELS-EXT (and now RELS-INT) some are defined in the DC datastream, and yet others are object or datastream properties defined elsewhere. So a move towards a more declarative specification of what triples are generated would be a good idea I think - moving some of what is effectively specified in imperative java code into the content model architecture, which is effectively I think what you are proposing. I would support that. I think FORMAT_URI fits within that - the specification that this datastream property generates a triple is represented in java; maybe that specification should be declarative within a content model. Similarly, you point out you'd rather not have to have both an XML metadata datastream *and* effectively repeat in RELS-INT the same data, so that it gets propagated to the resource index. I think a parallel to this is the current DC datastream - here we have a case where triples are generated, but they don't have to be added to RELS-EXT - but the specification of what and how those triples are generated is in java. What could be interesting would be to define, at the content model level, *how* certain metadata datastreams should be translated into triples. For instance an XSLT could be defined in the content model specifying a translation to RDF; this would be a more generic solution - and this method could be used for the current DC datastream by including this to-RDF translation in the ContentModel-3.0 declaration. I need to familiarise myself in more detail with your work on Enhanced Content Models! Regards Steve -----Original Message----- From: Asger Blekinge-Rasmussen [mailto:a...@statsbiblioteket.dk] Sent: 03 July 2009 14:10 To: Steve Bayliss Subject: RE: [Fedora-commons-developers] FCREPO-441 ready for code review and merge Hi I have read your answers, and have a much clearer understanding of what you propose. I really feel there are some duplicate responsibility between DS-COMPOSITE-MODEL and RELS-INT. Yes, I know, that DS-COMPOSITE-MODEL is defined on the content model level, and RELS-INT is on the object level. At least it would be a step towards having a more flexible system for specifying datastreams. I would like to work on that. Would it be something you would also be interested in? This reminds me: Should we move attributes like FORMAT_URI, defined at the datastream level into RELS-INT? At the moment we have two ways of specifying properties about datastreams, which feels wrong. Further answers down in the quoted text. Regards On Fri, 2009-07-03 at 13:52 +0200, Steve Bayliss wrote: > I've attempted to answer your questions inline, let me know if my answers > make sense! > > > -----Original Message----- > > From: Asger Blekinge-Rasmussen [mailto:a...@statsbiblioteket.dk] > > Sent: 03 July 2009 12:17 > > To: Steve Bayliss > > Cc: fedora-commons-developers@lists.sourceforge.net > > Subject: RE: [Fedora-commons-developers] FCREPO-441 ready for code review > and merge > > > > > > Okay, let me see if I understand you correctly. > > > > 1. You can repeat information stored in a datastream to the RELS-INT > > stream, to make it accesiable from the Resource index. > > Assuming you are talking about some metadata stored in some other > datastream, yes > (assuming that the metadata is "about" a datastream rather than the object > as a whole). > > So you could for example have an XML metadata datastream which contained > technical > metadata for a particular image datastream, you could then populate RELS-INT > with > this technical metadata so it was available in the resource index. > > > 2. Given the name of the "hasDatastream" relation (which I do not > > recall, but know exist) you can query about objects with certain > > RELS-INT properties. > > There is a fedora-view:disseminates relation created automatically from the > object to each datastream. > > (There are also some other relations created automatically, eg > <some-datastream> <fedora-view:lastModifiedDate> 'some-date' > Similarly the mime-type of a datasatream is automatically propagated > to the resource index as a relationship with the datastream as a subject) > > So yes, you can query about objects with certain RELS-INT properties - you > can make > use of the automatically-created relationship between the object and its > datastreams > to return the URIs of objects that contain datastreams that have certain > properties. > > > There is no way to validate whether or not the properties defined in > > RELS-INT is valid for the datastreams the specify? Or, in other ways, > > how are RELS-INT linked with the specified datastream? > > I'm not sure if I understand what you are asking here - could you give some > example? Let me explain. I was unhappy with having to specify the same data both in the datastream, and in RELS-INT. I was asking if there was a way to make the object of the property some data taken dynamically from the datastream. But this is not what you have been doing. You have made a system for, in a fedora object, specifying object properties with a datastream id as subject. No more, no less. > > RELS-INT is at the object level; the relationships/assertions are "linked" > with specified datastreams by having the datastream URI as the subject, ie > as the rdf:about attribute of the rdf:Description element(s) > > > I do not know if you are familiar with the enhanced content models > > (ecm.sourceforge.net) but we use OWL ontologies (in the content models) > > to specify the contents of the RELS-EXT datastream. I will have to think > > the implications through, but the very same system could easily be used > > to specify rules for required and allowed RELS-INT properties. > > Yes, that does sound feasible. That will then be one of the features added, then. When you make design documents, I will update the enhanced content models. > > > A RELS-INT property, what can it point to? Can I use it to specify a > > relation from one datastream to another? And if this other datastream is > > in another object? Is this allowed? > > Yes, that is fine. The object of the relationship can in fact be either > a literal or any "valid" URI - it can "point" to anything (as is the case > for RELS-EXT). > > Regards > > On Fri, 2009-07-03 at 10:57 +0200, Steve Bayliss wrote: > > No design documents at the moment other than what's written below and > what's > > written in the Tracker item - but feel free to ask if you have specific > > questions. Once it's in the trunk, I will write some documentation on how > > to use it. > > > > Essentially you can do everything that you can do with RELS-EXT, but with > a > > datastream URI as the subject of relationships, rather than a digital > object > > URI (but with some validation restrictions). > > > > Maybe an example would help: > > > > RELS-INT: > > > > <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; > > xmlns:exif="http://ns.adobe.com/exif/1.0/";> > > <rdf:Description rdf:about="info:fedora/demo:SmileyPens/MEDIUM_SIZE"> > > <exif:PixelXDimension>320</exif:PixelXDimension> > > <exif:PixelYDimension>240</exif:PixelYDimension> > > </rdf:Description> > > <rdf:Description rdf:about="info:fedora/demo:SmileyPens/FULL_SIZE"> > > <exif:PixelXDimension>800</exif:PixelXDimension> > > <exif:PixelYDimension>600</exif:PixelYDimension> > > </rdf:Description> > > </rdf:RDF> > > > > You could then issue the following (with a Mulgara resource index) to find > > all datastreams with particular image size properties: > > > > select $s $p $o > > from <#ri> > > where > > $s <http://ns.adobe.com/exif/1.0/PixelXDimension> '320' > > and > > $s <http://ns.adobe.com/exif/1.0/PixelYDimension> '240' > > > > (You could modify this to give the digital object URI as well as the > > datastream URI). > > > > Regards > > Steve > > > > > > > > -----Original Message----- > > From: Asger Blekinge-Rasmussen [mailto:a...@statsbiblioteket.dk] > > Sent: 03 July 2009 08:59 > > To: Steve Bayliss > > Cc: fedora-commons-developers@lists.sourceforge.net > > Subject: Re: [Fedora-commons-developers] FCREPO-441 ready for code review > > and merge > > > > > > Hi > > > > I was very much looking forward to this. Do you have any design documents > > written so far? > > > > Depending on some details, this might have great implications for Enhanced > > Content Models > > > > Regards > > > > On Thu, 2009-07-02 at 14:03 +0200, Steve Bayliss wrote: > > > I've created a branch for FCREPO-441, and implemented the necessary > > > changes (created from the trunk this morning). > > > > > > This is now ready for review. > > > > > > Implementation notes: > > > > > > * RDF in RELS-INT is now parsed and triples are propagated to resource > > > index > > > * The subjects of RELS-INT relationships must be syntactically-valid > > > datastreams for the object in which RELS-INT resides (but the > > > datastream does not have to exist) > > > * Multiple subjects are allowed in a single RELS-INT datastream (ie > > > multiple <rdf:Description ref:about="..." ... />), to allow assertions > > > to be made about several datastreams > > > * Validation is otherwise as per RELS-EXT, except Dublin Core > > > assertions are allowed, and some specific fedora-model assertions > > > which are allowed for RELS-EXT are not allowed for RELS-INT > > > * local server demos - image collection demo - contains some examples > > > of RELS-INT, in SmileyPens and SmileyGreetingCard (these are also used > > > in system tests) > > > * No changes made to the API (this will require some discussion and > > > agreement on what should be implemented) > > > * No changes made to the java client application (though of course > > > RELS-INT can be edited as per any other XML datastream) > > > > > > Any volunteers to review this change? > > > > > > If there's any interest I could also create a patch against 3.2.1. > > > > > > Many Thanks > > > Steve > > > > > > ------------------------------------------------------------------------------ _______________________________________________ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
