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