Re: [Fedora-commons-developers] Ontologies for the RELS-EXT datastream and Content Models
Thanks Chris, this really increased my understanding of the CMA. I had
not separated the constraints on the persistence object (Fedora
hasModel) from the constraints and assertions about the domain object
(potentially rdf:type). Since these objects are not 1:1 the same thing
in our system, the CMA had previous seemed to sort of "flatten out" out
our domain model.
So my reservations are gone, but I still need to understand how the
whole thing might fit together.
skål,
Greg
Chris Wilper wrote:
> Hi Kåre and Greg,
>
> Kåre said:
>
>> The previous CMODEL object property actually used rdf:type
>> as it's URL, but the new Content Model Architecture has opted
>> for a different approach, using the property "hasModel" in
>> the fedora vocabulary.
>>
>
> The decision not to use rdf:type in the CMA was deliberate,
> and deserves some explanation.
>
> Going into the CMA design process, we made a couple basic
> assumptions:
> 1) Special Fedora objects should serve to identify and
>describe content models.
> 2) All objects in Fedora should be describable via
>a content model.
>
> This means that even content model objects (our "classes")
> are able to assert that they are in a content model.
> You can see this in the demo content models -- each has
> a "hasModel" relationship to the system-defined content
> model for content models.
>
> Modeling this in OWL (and thus using rdf:type instead of
> "hasModel") was certainly possible, but it quickly put us
> in OWL-Full territory because classes cannot be instances
> ("clinstances") otherwise.
>
> So we decided (no pun intended) to use "hasModel" without
> tying this core CMA relationship to OWL for now, noting
> that it doesn't preclude a future move of declaring "hasModel"
> as a subproperty of rdf:type. Note that regardless of such a
> move, since content models themselves are instances, we'd
> already be in OWL-Full.
>
> Greg said:
>
>> My suggestion would simply be to make your rdf:type
>> statements in the RELS-EXT datastream and leave the
>> contentModel field alone. The reason is that I see no
>> semantic benefit to using the contentModel property of
>> the Fedora object,
>>
>
> The "hasModel" relationship brings semantics to the party
> that rdf:type doesn't -- it provides a standard way to
> hook into a description of the "class" of Fedora Object
> of which the referrer is a member. Among other useful
> things, this information can be used to drive Fedora Object
> validation all the way down to the bitstream format level.
>
>
>> while on the other hand it imposes some limitations.
>> First, your objects have single inheritance.
>>
>
> I'm not sure what you mean by inheritance here, but
> I just want to clarify in case there's any confusion:
>
> A) Fedora Objects can assert that they adhere to
>multiple content models at once via multiple "hasModel"
>relationships. The beta1 version of 3.0 was limited
>in this regard.
> B) As of 3.0, each content model is expected to be
>self-contained. We have not defined or implemented
>a "subclassing" feature whereby membership in one
>content model implies membership in another.
>
>
>> Second, we don't really know where the
>> CMA is going in future releases, especially in terms
>> of schema validation.
>>
>
> We hope to have laid a solid foundation without precluding
> the innovation that needs to happen in this area, but this
> is an ongoing process. Where the CMA goes in future
> releases depends on exactly these types of discussions.
>
>
>> So in my humble opinion it is
>> premature to tie yourself to that architecture.
>>
>
> Hmmm.. I don't think it has to be an either/or thing.
>
> It is typically the case that there is a 1:1 relationship between a
> persisted Fedora object and a domain object, but we shouldn't
> forget that they're different things. When modeling such domain
> objects in RDF/OWL, it seems that rdf:type is the right way to
> go. But "hasModel" speaks more to the persistent nature of
> the thing as a Fedora object.
>
> Cheers,
> Chris
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Fedora-commons-developers mailing list
Fedora-commons-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
Re: [Fedora-commons-developers] Foxml namespace in dom4j / Java
Frank, it looks like you didn't include the '#' sign on the end of the
namespace URL. You will need that.
Greg Jansen
Carolina Digital Library Developer
UNC Chapel Hill
\yf508 wrote:
> Hi all,
>
> I have a problem while dealing with foxml document by using dom4j in our
> project. The namespace of foxml ("info:fedora/fedora-system:def/foxml#") is
> not working in my program. Any suggestions?
>
> Thanks
>
> Frank
>
>
> P.S. The code fragement is shown below:
>
> HashMap map = new HashMap();
> map.put("vra", "http://dlib.york.ac.uk/vra4york";);
> map.put("foxml", "info:fedora/fedora-system:def/foxml");
>
> XPath xpath =
> DocumentHelper.createXPath("//foxml:datastream[ID='"+dsId+"']/foxml:datastre
> amVersion[last()]/vra:vra");
> xpath.setNamespaceURIs(map);
> org.dom4j.Element vraElt= ((org.dom4j.Element)
> xpath.selectSingleNode(foxmlDoc.getRootElement())).createCopy();
>
>
> -
> Dr. Yankui(Frank) Feng
> Digital Library Systems Developer
> The University of York
> Heslington, York, YO10 5DD, UK
> Tel: +44 (0) 1904-434507
> Email: yf508 at york.ac.uk
> -
>
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Fedora-commons-developers mailing list
> Fedora-commons-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Fedora-commons-developers mailing list
Fedora-commons-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
[Fedora-commons-developers] converting datastream from external to managed
Hello Fedora folks, Is it possible to convert a datastream from external to managed while retaining the ID or do I have to purge and create it again? This comes from a desire to gradually and carefully migrate many large files into Fedora-managed storage through some kind of background replication task. Also, any interest in sharing a Spring WS-based Fedora client or client demo? I don't know how widespread Spring is in the Fedora community, but this is a client that I've been working on for our project. It is also a Maven2-based project, making it easy to include in other Maven projects. thanks for advising, Greg __ Greg Jansen Developer - Carolina Digital Repository University of North Carolina at Chapel Hill - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
[Fedora-commons-developers] contentDigest FOXML element on API-M ingest
Is it supported to use the contentDigest element when ingesting via API-M SOAP? I've sometimes got a checksum for incoming files and I'd like to fail/recover if the Fedora checksum doesn't match. I thought by added the checksum to the FOXML I'm sending Fedora that it would verify and only ingest if they match. When I set the contentDigest element with DIGEST specified, I get this: fedora.server.errors.ObjectIntegrityException: FOXML IO stream was bad : Checksum Mismatch: ExceptionReadingStream I've verified that my MD5 digest is the same string Fedora generates for the file if I ingest it through the admin client. Is there a way to verify that Fedora checksum is the same as mine without finishing the ingest operation, thereby creating an object with potentially corrupt data, and comparing afterward? many thanks, Greg ___ Greg Jansen Carolina Digital Repository University of North Carolina at Chapel Hill -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
Re: [Fedora-commons-developers] Fedora with ontologies and enhanced content models
I think this is a very promising direction and was pleased to learn about the Fedora handler/decorator implementation. I use RDF graphs during pre-ingest processing to test AIP requirements. It becomes really useful when an ingest transaction spans many interrelated objects and you want to validate their relations before adding them. An in memory RDF graph is simpler and a smaller footprint for this sort of thing than juggling multiple XML documents/files. In the long run I'd really like to use RDF "reasoning" to discover opportunities for object enhancement across the repository, such as text extraction and format conversion. Greg Jansen Carolina Digital Repository Chris Wilper wrote: > Hi Asger, > > This looks like an impressive body of work. Thanks for sharing it > with us. I will certainly be taking a closer look and would like to > encourage others to try it out and offer their thoughts/experiences. > > - Chris > > On Mon, Feb 2, 2009 at 8:36 AM, Asger Blekinge-Rasmussen > wrote: > >> Hi >> >> First draft of the installation guide are up. I will use the rest of >> today to remove the hardwired references from the code, and introduce >> config files. >> >> Regards >> Asger >> >> On Wed, 2009-01-14 at 15:06 +0100, Asger Blekinge-Rasmussen wrote: >> >>> Hi >>> >>> We at the State and University Library in Denmark have been working on >>> some new functionality for the Fedora system. >>> >>> >>> This is a very brief description of what we have been doing. >>> >>> Fedora is at the core of the new DOMS (Digital Object Management System) >>> which is being developed at the State and University Library in >>> Aarhus/Denmark. For this system, we needed more powerful content models. >>> More specifically, we needed content models that specify the xml schemas >>> for datastreams, cardinality restrictions on relations and allowed types >>> for the targets of relations. In addition, we needed to retain >>> compatibility with the original Fedora system. >>> >>> We did this by enhancing the content models and building a validator >>> which can validate objects against the new enhanced content models. In >>> addition, we hooked the API-M module, so that the validator is invoked >>> on changes in a way guarantees that the data objects in d the repository >>> stay consistent. >>> >>> Everything we have been doing is released under the Apache 2.0 license. >>> We have made a page for this project on the Fedora Wiki - >>> http://fedora-commons.org/confluence/display/DEV/Fedora+Enhanced+Content >>> +Models >>> >>> Our hope is that this could become a standard part of Fedora, but for >>> now we just want to unveil it to the community and receive your >>> feedback. So, feel free to write me or leave comments. >>> >>> Regards >>> Asger Blekinge-Rasmussen >>> IT-developer >>> State and University Library >>> Denmark >>> > > -- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > ___ > Fedora-commons-developers mailing list > Fedora-commons-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers > -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
[fcrepo-dev] m2 repositories
Hello Dev list, I need to update some modules against Fedora 3.3 and later 3.4. I'm having trouble resolving maven dependencies for third party jars. In fact, I also cannot reach the releases m2 repository. I can compile those project locally of course, but still need to reach the third party repository. The parent project for fcrepo lists these additional repositories, but they all return 404 for me: https://fedora-commons.org/m2/content/repositories/releases https://fedora-commons.org/m2/content/repositories/thirdparty https://fedora-commons.org/m2/content/repositories/snapshots Anybody having better luck with this? thanks in advance, Greg -- ___ Gregory N. Jansen Developer - Carolina Digital Repository UNC Chapel Hill Libraries -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
Re: [fcrepo-dev] Customize Fedora's Ontology
Hello Laura, Fedora may have more than one ontology, depending on how you look at it. The system creates a graph with it's own predicates representing each object and datastream. There are also a set of Fedora "view" predicates, which are used to indicate disseminations available for an object. Lastly, there is a sort of default Fedora ontology for defining relationships *between* objects. Some people use this default ontology and other don't. You can create any triple you like in RELS-EXT RDF, as long as the subject is the PID of the object in question. We use SPARQL queries against our Fedora triple store. However, we opted to install Mulgara as a stand-alone application. So we are using the Mulgara SPARQL REST interface. If you use the Fedora-installed Mulgara, then you may have a different endpoint. Greg Jansen On 02/23/2011 02:47 AM, Laura delli Paoli wrote: > Hi! > I'm studying Fedora repository for my thesis and I'd like to know how > to customize fedora's ontology! > My ontology is a rdf schema (*.rdfs) and, of course, I need to extabilish > relationship between objects and to interrogate the repository using sparql > queries. > Can anobody help Me? > Thanks > Laura > > > > -- > Free Software Download: Index, Search& Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > ___ > Fedora-commons-developers mailing list > Fedora-commons-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers -- ___ Gregory N. Jansen Developer - Carolina Digital Repository UNC Chapel Hill Libraries -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
[fcrepo-dev] PEP.java and problems with large disseminations
Hey folks, I've been seeing long delays and memory filling up when Fedora is disseminating a large data streams. The same behavior may also be present on smaller streams, but is not as noticeable. We have some 2GB Wave files in our repository, which will trigger OOM exceptions if downloaded this way. We are using FeSL here and from looking over the relevant Fedora code, it looks like the PEP.java servlet filter class is wrapping and potentially buffering the whole request in memory via the DataResponseWrapper. out.write(res.getData());// returns a byte array containing the whole request out.flush(); Is this the expected pathway for a data stream dissemination request? It seems like even a couple simultaneous small files could fill the heap. This makes me think I've configured it improperly somehow. thanks for your help, Greg Jansen p.s. Here is the stack trace that I generally get if I trigger this when the JVM isn't doing anything else: SEVERE: Servlet.service() for servlet RestServlet threw exception java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2786) at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) at java.io.DataOutputStream.write(DataOutputStream.java:90) at org.fcrepo.server.security.xacml.pep.rest.filters.DataServletOutputStream.write(DataServletOutputStream.java:71) at com.sun.jersey.spi.container.servlet.WebComponent$Writer.write(WebComponent.java:230) at com.sun.jersey.spi.container.ContainerResponse$CommittingOutputStream.write(ContainerResponse.java:114) at com.sun.jersey.core.provider.AbstractMessageReaderWriterProvider.writeTo(AbstractMessageReaderWriterProvider.java:73) at com.sun.jersey.core.impl.provider.entity.InputStreamProvider.writeTo(InputStreamProvider.java:95) at com.sun.jersey.core.impl.provider.entity.InputStreamProvider.writeTo(InputStreamProvider.java:58) at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:254) at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:724) at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:647) at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:638) at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:309) at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:425) at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:590) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) -- ___ Gregory N. Jansen Developer - Carolina Digital Repository UNC Chapel Hill Libraries -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
[fcrepo-dev] review of FeSL REST filters patch?
Hey Fedora Devs, We're using FeSL on our server and ran into this issue: https://jira.duraspace.org/browse/FCREPO-1020 I made a patch for it and I'd really like to have anyone with FeSL experience take a look. We're about to deploy this thing, which seems to work fine on our test server and definitely addresses the performance/memory issues. Patch is all in one commit over here: https://github.com/UNC-Libraries/fcrepo/commit/f82b7ca25ba491fd3f411dd0e3d28d2d37acfbe4 any help is appreciated, Greg -- ___ Gregory N. Jansen Developer - Carolina Digital Repository UNC Chapel Hill Libraries -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
Re: [fcrepo-dev] Fedora failing under heavy load - debugging theissues
I think you're right about logging and exception handling being the first step, along with some refactoring of the long doCommit() method. We're pushing hundreds of gigabyte WAV files into our Fedora and we have a modified low-level storage module with it's own failure modes. These logging improvements would go a long way toward helping us diagnose LLS issues and repair the data. Short of some kind of write-ahead logging or JTA, it might help to create a parallel log appender for commit-level errors, i.e. ingests and modifications that fail. We also use the triple store pretty extensively in an ingest-synchronized way. It would be great if that update could be considered part of the overall commit/rollback. Greg On 11/17/2011 05:44 AM, Stephen Bayliss wrote: > I wonder if JTA isn't the way to go on this. > > But I think it would be useful to limit the scope to the objectives and > goals of 3.6; and recognise that full transaction handling is something for > the future; and we may not want to start down a track now that sets a > direction that sets us on a course that may need to change in the future. > > Around the 3.6 theme of scalability: being able to debug and understand > what's going on when Fedora fails under heavy ingest/modification load with > a number of threads would seem like a useful objective. > > The current "commit" code handles exceptions/errors thus, as far as I can > see (at a high level): > > 1) On ingest: if there is a failure > - an exception is thrown and caught > - tidy up by doing a purge, reporting any purge failures as warnings > - re-throw as ServerException > - reported as WARN in the logs by REST API exception handling > > 2) On a modify > - an exception is thrown and caught > - no attempt at tidy-up > - re-throw ServerException > - reported as WARN in the logs by REST API exception handling > > So first stage improvements could be: > > a) For each "store" (object, datastream, resource index, registry, > fieldSearch) record (just a boolean flag) whether or not changes were > successfully made. > b) Revise handling of Ingest tidy-up code: Don't use the current purge code, > but instead explicitly tidy-up whichever of the stores were updated. Log > error messages if tidy-up did not succeed. > c) Change error logging in the purge code to ERROR (they are WARN at the > moment because of the re-use of the purge code for ingest tidy-up) > d) Ensure an explicit ERROR is logged for the ingest failure when one of the > stores failed to be updated (currently I think the exception just bubbles up > and is reported as a WARN by eg the REST API exception handling). > > This would at least give us greater insight of what's happening when there > is a failure under heavy ingest. > > The next stage could be: > > a) Revise other error logging in doCommit() so that an explicit ERROR is > logged if an update to a store fails. The current exception handling for > the REST API catches the exceptions and logs these in general as WARN; so > we're unable from log analysis to easily trawl log files and distinguish > between eg invalid requests, invalid FOXML etc and a failure in persisting > modifications to an object. There is a danger here though of confusing > errors from invalid requests (eg deleting a datastream that doesn't exist) > with genuine errors from the doCommit(). We'd need a review of > DefaultManagement code to see when detecting an error in the request is > reliant on bubbling up exceptions such as ObjectNotInLowLevelStorage from > the commit, so we could distinguish between deleting a datastream that does > not exist vs deleting a datastream failing because the expected file isn't > present - though from a quick look error handling for requests on > non-existent content isn't reliant on these. > b) Revise other error logging elsewhere to ensure we are distinguishing > between genuine repository errors (which should be logged as ERROR) and eg > requests for non-existent objects and datastreams (As an example - try > deleting the file from the object store for a managed content datastream; > and then try and delete the datastream in Fedora - you'll get a 200 response > with a WARN in the log, with a stacktrace showing that doCommit failed). > > And then: > > a) Implement basic transaction/rollback handling - this should be at the > level of recording what changes have been made to each individual store for > a single request so they can be backed-out in case of failure. This would > reduce instances of an inconsistent repository when modifications fail. But > I do wonder here whether this is straying outside of the 3.6 remit (and it > has the risk of degrading performance potentially). > > Steve > > > > > >> -Original Message- >> From: Scott Prater [mailto:pra...@wisc.edu] >> Sent: 17 November 2011 05:54 >> To: fedora-commons-developers@lists.sourceforge.net >> Subject: Re: [fcrepo-dev] Fedora failing under heavy load - >> debugging theissues >> >> >> Hmmm...
Re: [fcrepo-dev] Fedora failing under heavy load - debugging theissues
I agree with this, as long as the non-canonical stores are updated after all the canonical stores have a chance to fail. Greg On 11/18/2011 03:07 AM, Stephen Bayliss wrote: > We should try and ensure the integrity of the "canonical datastore". > > And maybe in considering any rollback-type behaviour we should consider if > changes to the "canonical datastore" have been made successfully, but > updates to RI, FieldSearch, Registry fail then we don't rollback changes to > the "canonical datastore" but just log errors? > > Steve > >> -Original Message- >> From: Michael Della Bitta [mailto:michaeldellabi...@nypl.org] >> Sent: 17 November 2011 15:06 >> To: pra...@wisc.edu; fedora-commons-developers@lists.sourceforge.net >> Subject: Re: [fcrepo-dev] Fedora failing under heavy load - >> debugging theissues >> >> >>> Hmmm... doesn't that just push the problem farther downstream? >> It definitely doesn't solve the concurrency problem with the >> various datastores. But it does solve the problem of corrupt >> data being written to the canonical datastore, which is the >> filesystem. As it stands now, the other stores are meant to >> be rebuilt from the filesystem when there's a problem. >> >> Michael Della Bitta >> >> Senior Applications Developer >> Information Technology Group >> The New York Public Library >> 40 West 20th Street, 5th Floor >> New York, NY 10011-4211 >> (212) 621-0609 >> >> -- >> >> All the data continuously generated in your IT infrastructure >> contains a definitive record of customers, application performance, >> security threats, fraudulent activity, and more. Splunk takes this >> data and makes sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-novd2d >> ___ >> Fedora-commons-developers mailing list >> Fedora-commons-developers@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers >> > > -- > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > ___ > Fedora-commons-developers mailing list > Fedora-commons-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers -- ___ Gregory N. Jansen Developer - Carolina Digital Repository UNC Chapel Hill Libraries -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
