Some ideas relevant to this were discussed at the recent London committer meeting.
There's a wiki page [1] and a presentation [2]; comments are welcomed on these. Regards Steve [1] http://fedora-commons.org/confluence/display/DEV/Supporting+the+Semantic+Web +and+Linked+Data [2] http://www.fedora-commons.org/confluence/download/attachments/15368195/Steve +-+semweb%2C+RI%2C+etc+overview.pdf?version=1&modificationDate=1270636050922 > -----Original Message----- > From: Walker Sampson [mailto:[email protected]] > Sent: 26 April 2010 15:27 > To: Scott Prater > Cc: Fedora Users > Subject: Re: [Fedora-commons-users] support for Dublin Core > "dcterms:"namespace > > > 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 > ------------------------------------------------------------------------------ _______________________________________________ Fedora-commons-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
