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?)
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?) 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; 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?*) 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? Thanks again, and again apologies if I'm missing something that should be obvious, greetings, Andrew * https://wiki.duraspace.org/download/attachments/4718930/tutorial2.pdf?version=1&modificationDate=1218446070039 <https://wiki.duraspace.org/download/attachments/4718930/tutorial2.pdf?version=1&modificationDate=1218446070039> El 08/06/11 17:14, Conal Christopher Tuohy escribió: > Hi Andrew. I'm quite new to working with Fedora, too, but I've got similar > needs I think. > > My understanding of the special RELS-EXT RDF-XML datastream is that it is > strictly limited to making assertions in which the subjects are Fedora > objects (though there are no restrictions on predicates and objects). See > https://wiki.duraspace.org/display/FCR30/Digital+Object+Relationships > > This restriction may or may not be a concern for you. > > So you may therefore use external authority files, thesauri, etc, or you may > choose to model your contextual entities as Fedora objects. > > In a project I'm working on, we are doing both. > > > > Andrew Green<andrew.green...@gmail.com> wrote: > > > Hi, all, > > I'm just learning Fedora Commons and have a question about metadata > modeling. As far as I can tell, the standard XML metadata stream does > not provide much structure for metadata---it seems that, normally, the > values of metadata properties are just stored as strings. So, for > example, a reference to an author would not point to a unique author > identifier, but would just store the person's name as a string. Is this > correct? > > So are RDF streams the place Fedora offers for storing structured data > in general? I understand that this is for relationships within and among > digital objects. This is great (and completely aligned with the project > I've been working on---see below) though many, many of the entities I > need to define relationships to (like people, institutions, places, > thesaurus terms and external publications) would not normally be > considered "digital objects" in the repository. > > What is the standard practice here for working with data in a structured > manner, including the modification and addition of data? Does one keep a > copy of everything in a relational database or some external tool, and > export it to the flat XML format on a regular basis? Or does one store > structured metadata in RDF streams, and create digital objects for > everything, including things that aren't stored in the repository in any > way? Or not, and just reference non-digital-objects (like people and > places) from the RDF in the Fedora repository, and use a separate RDF > store for additional triples describing those objects? And in the case > of either of these two RDF-centered approaches, what systems might one > use for modifying/maintaining/creating the metadata? > > To give you an idea of where I'm coming from, let me say a bit about the > project I work on: over the course of several years, we've created a few > versions of a Semantic Web-based repository system, focused on the > specific needs of photograph archives researched and disseminated by the > institution we're based at. You can see the results of our work at > http://lais.mora.edu.mx/ff/. To see how structured data works for us in > our complex, specific (though standards-based) metadata format, go to > the "Catálogo" tab, and try searches for "centro", "roca" or "plano". > (In Spanish only, I'm afraid; but if you know at least a bit of any > Romance language, you can probably get the gist of what's going on.) Our > system, called Pescador, works for our Web site, but is limited in many > ways. We're now making plans for the future development of this system, > and are considering ways of integrating what we've done with the wider > ecosystem of free software archival systems, which has really grown up > since we started our work. You can see our source code---all GPL'd---at > http://lais.mora.edu.mx/svn/pescador/trunk/. > > Many thanks in advance for your help (and apologies if the answers to my > questions are already available somewhere that I should have seen and > haven't), greetings, > Andrew Green > > > > > > ------------------------------------------------------------------------------ > 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 > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
