I voted for the feature too, my only apprehension being that more choice in how DC or RELS-EXT are managed could present more complexity, bugs, and issues in the future.
That said, it seems like the datastreams as managed content could be used really well. Particularly RELS-EXT, which could use any number of namespaces to build very specific relationships. This is immediately what came to mind when I first read about relationships, as opposed to relationships that would specify web services, etc. Walker On Mon, Apr 26, 2010 at 9:10 AM, Scott Prater <[email protected]> wrote: > 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 > ------------------------------------------------------------------------------ _______________________________________________ Fedora-commons-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
