This brings up an interesting question... is RELS-EXT to be used only for internal Fedora bookkeeping purposes, to link objects together in ways that Fedora understands?
I could imagine a use case where RDF documents that contain much richer information about the objects and their relationships to each other, information that is specific just to your collections and web services, could be stored as separate managed content datastreams, then indexed, searched, and retrieved separately from the Fedora resource index via disseminators linked to a SPARQL web service. This would keep your site-specific data and services loosely coupled to Fedora, not place so much dependency on the way Fedora implements and uses RELS-EXT internally. All that aside, I also think that allowing RELS-EXT and DC to be any one of the four kinds of datastreams is a good idea, and I voted for the issue. -- Scott [email protected] wrote: > Thorny-- > > Can you speak to RELS_EXT in this light? RELS-EXT, as I understand it, is > normally stored as inline XML. > > We're making efforts to expand our Semantic Web presence by publishing more > metadata out through RDF and thereby exposing it at the SPARQL endpoint that > the Resource Index supplies. Will this not eventually lead to "bloat" in the > object XML? Is there a better way to expose metadata through RDF without > using RELS-EXT as a "way station"? > > --- > A. Soroka > Digital Research and Scholarship R & D > the University of Virginia Library > > > > On Apr 24, 2010, at 6:12 PM, thornton staples wrote: > >> It is really much better to create your own datastream for metadata that >> you want to use externally. I wish we had called the DC datastream >> "repoMeta" or something. It was just intended to be the base metadata >> needed for the repository manager to be able to function and was not >> intended to be exposed externally. We just used Dublin core because it >> was as close to a basic schema as we could get at the time. The "basic >> search" that is built-in was only intended to be a management tool. >> >> It would also be better not to use an in-line datastream for any >> metadata datastream, as a general rule. If your FOXML files get larger >> than 20-30 K it can affect performance for most applications. Metadata >> records can really bulk up that file pretty quickly if you are not >> careful. Use a managed content datastream, and use any kind of metadata >> you like. >> >> ____________________________________ >> Thornton Staples >> Director of Community Strategy and Alliances >> Director of the Fedora Project >> DuraSpace, Inc. >> [email protected] (202) 684-6952 >> skype: thorny.staples www.duraspace.org >> >> >> On 4/24/10 2:53 PM, Walker Sampson wrote: >>> Hi all, >>> >>> I have been migrating some old records from MySQL to Fedora, and have >>> been using some of the newer DC terms available since December 2006 in >>> the "dcterms" namespace: http://purl.org/dc/terms/. >>> >>> It seems the compulsory DC datastream defaults to the "dc" namespace >>> (http://purl.org/dc/elements/1.1/). I went ahead and changed this in >>> my FOXML files to the newer one, hoping it might add support for new >>> terms like "alternative", "extent" and so on. >>> >>> Upon ingestion however it looks like only those terms which are also >>> in the legacy namespace come through, and the >>> "http://purl.org/dc/terms/"; value gets replaced with the >>> "http://purl.org/dc/elements/1.1/"; value. I assume then that Fedora >>> doesn't support the new terms in its DC datastream. If so, has there >>> been a statement on when this might come to pass? Or does anyone know >>> a way to have these elements shown in the DC datastream after ingest? >>> >>> Assuming Fedora isn't going to work with these elements on this >>> release, my solution will be to add in a custom inline datastream >>> holding these values for me. >>> >>> Anyone had experience with this issue? >>> >>> Thanks- >>> Walker >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Fedora-commons-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users >>> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Fedora-commons-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users > > > ------------------------------------------------------------------------------ > _______________________________________________ > Fedora-commons-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users -- Scott Prater Library, Instructional, and Research Applications (LIRA) Division of Information Technology (DoIT) University of Wisconsin - Madison [email protected] ------------------------------------------------------------------------------ _______________________________________________ Fedora-commons-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
