This Confluence wiki site, maintained by DuraSpace prior to the recent merger with LYRASIS, will transition from the duraspace.org domain to the lyrasis.org domain on Saturday, Nov 16 beginning at approximately 7pm ET. A period of downtime of 2-3 hours is expected. After the transition, this wiki will be available at https://wiki.lyrasis.org/. All links to duraspace.org wiki pages will be redirected to the correct lyrasis.org URL. If you have questions prior to or following the transition please contact: wikihelp@lyrasis.org.
Page tree
Skip to end of metadata
Go to start of metadata

These training archives may be out of date, but have been retained and kept available for the community's benefit in reviewing previous sessions.

Current training documentation can be found here: Training

  1. Background: Your Fedora repository is a part of the Web
    1. What are the special qualities of your part of the Web?
      1. Durability
      2. Connections to the particular communities you serve.
    2. What qualities does your part of the Web share with the rest of the Web?
      1. HTTP, RDF, and RFDS/OWL/SKOS as common "languages"
    3. Good choices for syntax and semantics help us support our values
      1. We're interested in durability
        1. For syntax, that means sharing your syntax with a big community. HTTP does this.
        2. For semantics, that means sharing your semantics with a community committed to the same worldview. RFDS/OWL/SKOS help with this.
          1. More and more communities are publishing their common semantics in these languages. Can you think of some in use for your community?
      2. We're interested in extensibility
        1. Extensible syntax is minimal but powerful. HTTP with RDF is that.
        2. Extensible semantics choose for localizing assumptions like OWA and against global conditions like UNA.
      3. We're interested in interoperability.
        1. Common syntax is completely necessary to interoperability.
        2. Common semantics lowers the cost of interoperability.
  2. Moving Fedora 3 concepts forward (Content Modeling)
    1. Fedora 3 content modeling did a lot of things at once!
      1. Ontology
      2. Workflow
      3. Validation
    2. Where do these all go in Fedora 4?
      1. Ontology
        1. Ontology often involves resources outside the repository
          1. "This resource is of type X, which is itself a resource maintained outside the repository."
          2. These kinds of ontological assertions can be maintained inside the repository, but inference based on them should be supported outside the repository.
        2. But sometimes ontology involves relationships entirely within the repository.
          1. "This resource is of type Y, which is itself a resource maintained inside the repository."
          2. These kinds of ontological assertions can be maintained inside the repository, and inference based on them could be supported inside the repository.
          3. It's not yet clear how "active" users would like the repository to be.
            1. Fedora pre-4 was almost entirely passive, without any real inferencing abilities.
      2. Workflow
        1. Outside the repository, at least in most circumstances
        2. Apache Camel is now under extensive investigation
      3. Validation
        1. The Web ontology languages don't really support validation, only inference.
        2. RDF Shapes hasn't advanced very far and in any event, would cover only a fraction of Fedora's use cases
        3. It's not totally clear what kind of validation services are useful to Fedora users or whether they should be housed in the repository itself.
  3. Moving Fedora 3 concepts forward (Dissemination)
    1. Disseminators create representations
      1. This is similar to, but distinct from, the way representations appear in REST
        1. Fedora disseminations are created from multiple resources
        2. Fedora disseminations are always late-binding to Web services, via frightening, confusing, arcane syntax
        3. Fedora disseminations have been "one-way" (no mutation via dissemination)
    2. There is currently no equivalent notion of dissemination in Fedora 4
      1. Sequencers are available for early-binding construction of representations, typically from/for one resource
      2. For one particular use case, the transformation service is available
    3. It's not clear to what extent support exists in the community to redevelop the disseminator framework.
      1. What are your use cases?
  4. Making thoughtful commitments for the future
    1. Your commitment to Fedora appears in:
      1.  the way you manage your resources with respect to persistence, fixity, and other low-level technical aspects.
    2. Your commitment to the specific communities you serve appears in:
      1. what your resources mean (the vocabularies and ontologies you use to do content modeling) and
      2. your workflows, which are useful to the members of your communities.
  5. What does this look like in practice?
    1. Fedora is an object repository, not a triple store or general semantic store.
      1. Only put things in your Fedora repository for which only you are responsible
        1. For things for which the communities you serve are responsible, put them in other places (e.g. triple stores, Linked Data caches)
          1. Common vocabularies. What such vocabularies are you using now? Where are you storing or caching them?
          2. Common ontologies.
          3. Authorized facts (e.g. personal or corporate authority information).
      2. Don't build so that your repository is made responsible for anything other than the durability of your own stuff
        1. Don't provide discovery services directly over Fedora (don't use Fedora as an index).
        2. Don't use your repository to manage information that is ultimately transactional. E.g.,
          1. Identity management, groups management
          2. Workflow state a la Stanford "robot" systems (maybe an edge case)
    2. Choosing common vocabularies (common semantics) lets us share work with the communities that use those vocabularies
    3. Choosing common ontologies (common semantics) lets us share work with the communities that see the world that same way
  • No labels