On 11/06/11 07:44, Andrew Green wrote: > Hi, > > Thanks for your reply, Christopher... I guess I should have seen the > details on the page you mentioned. The other relevant restriction I see > there is one that forbids the use of Dublin Core namespace. So I guess > it's really expected that one use the DC-XML stream for all basic data > like author, instead of putting it in RDF? In that scenario, how do > people work usually work with that data in a structured way? (As in, for > example, how does one let cataloguers to select the author of an object > from a list of authors, rather than typing in the author's name each time?) Look at this way: you can in fact encode Dublin Core metadata in RDF if you want, and you can also encode any kind of relationships you wish (with whatever vocabulary) in RDF/XML; the restrictions which exist are only around the content of a few datastreams with the reserved names DC, RELS-EXT and RELS-INT. The reason for those restrictions is that these reserved datastreams actually constitute a kind of API for various subsystems within Fedora (i.e. the various indexes).
> Both in general and specifically with regard to the complex > relationships that can be stored in RDF-EXT, I'm still wondering what > kind of metadata editing tools people use. Does Islandora allow one to > say, for example, that the value of a property should always be chosen > from the members of a certain collection, and show cataloguers an > appropriate list of possible values when adding or updating records? > (Though, if that's the case, shouldn't such restrictions be specified as > part of the data backend, rather than in the interface?) Speaking for myself only, I've used XForms on the client side to edit XML datastreams, and I've implemented those kinds of features in the XForms layer, without any reliance on the Fedora content model system. > Also, in your second message, if I understand correctly, you suggest one > could add a custom RDF stream that wouldn't have the restrictions of > RDF-EXT and RDF-INT; It could be RDF/XML or some other XML vocabulary. But the point is you may choose whatever is convenient for your project. > you say one could "crosswalk" to the reserved > streams that have a special meaning. What exactly do you mean by > "crosswalk"? That one could import data from the DC, RDF-EXT and RDF-INT > streams into a custom, unrestricted RDF stream? Or that a custom stream > could contain cross-references to elements in the restricted streams? Or > that one could keep all data in a custom stream, and automatically > export data to the restricted streams, or generate them from the custom > stream? (Is this along the lines of what Tutorial #2 suggests on p. 17?*) I meant the latter - that you would keep your metadata in one or more streams of your own, and would transform those streams into the other formats and repopulate the DC, RELS-EXT, etc, streams. In a project I'm working on at the moment, we run a JMS client to listen for updates to the Fedora repository. Whenever an update happens, the JMS listener is sent an Atom XML message describing the update (it's rather like subscribing to a blog's feed, except that JMS is real-time, or near enough, and each message describes only a single item). In response to an update message, the JMS client launches an XProc pipeline which downloads the modified stream from the Fedora item, extracts the relevant data from it, encodes that data in DC, and uploads it back to the DC stream. This is still a work in progress (we are still working on the various pipelines), but the JMS client is publicly available already. See <http://code.google.com/p/ands-la-trobe/source/browse/#svn%2Ftrunk%2Ffedora-update-handler> Finally, I have to say, I'm a bit confused by the design of all this. > Doesn't it make more sense to keep everything (DC, internal and external > object relationships, other metadata) in one big RDF graph, and extract > data from that graph as required? Does anyone do this, or something similar? Yes, as I've stated above, that's pretty much what we're doing. I don't know if there's another way to achieve the same sort of result, using built-in Fedora systems, but in any case, I'm rather keen on the system with the JMS client and XProc pipelines which corresponds to a rather loosely-coupled architecture which I think is a healthy approach. Cheers C -- Conal Tuohy eResearch Business Analyst Victorian eResearch Strategic Initiative +61-466324297 ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
