It struck me that a page where the Fedora community could put together a "wish-list" of features for future versions might be useful... RG
ownerId
Requested by: Richard Green
<blockquote>
Many of the Fedora tools make reference to an object property 'ownerId' which I understand was never actually implemented. This would be extremely useful to us at Hull where we are developing the notion of "My Repository". For example, ownerId could be compared to a user's login credentials to establish ownership and therefore rights to an object. Further, we should like Fedora to support <i>multiple</i> ownerIds which would be very useful for small-group collaboration work.
</blockquote>
<p>
<blockquote>
<font color="navy">Single ownerID released in Fedora 2.2, multiple promised for 2.3</font>
</blockquote>
$pid
Requested by: Richard Green
<blockquote>
When ingesting a new object which is going to be part of an already existing collection it would be useful to be able to ingest a working RELS-EXT datastream describing the object's relationship with the collection. This requires a line of the form:
<p>
<rdf:Description rdf:about="info:fedora/$pid">
</p>
where $pid would be a placeholder for the pid that the system will assign to the object at ingest. Our current workaround of using getNextPID and inserting the result into each new object before ingest is somewhat cumbersome!__I_did_think_that_I_had_seen_an_e-mail_saying_this_was_already_possible_but_I_can't_find_it,and_a_posting_to_the_list_in_mid-June_didn't_produce_a_solution._
</blockquote>
_Using_Datastream/Disseminator_Values_in_Disseminators
Requested_by:_Ryan_Scherle
<blockquote>
Although_it_is_possible_to_pass_an_object's_datastreams_to_the_service_the_bmech_represents,making_use_of_the_object's_contents_within_the_bmech(before_the_service_is_invoked)almost_always_impossible._You_cannot_insert_thevalueof_a_datastream_directly_into_the_service_URL;_it_can_only_be_passed_to_the_service_by_reference._You_cannot_use_the_value_of_a_dissemination_in_a_mechanism,_unless_you_have_created_a_datastream_that_redirects_to_the_dissemination._Again,_the_best_you_can_do_is_gather_up_the_relevant_information_and_pass_it_to_a"helper_service"_that_repackages_the_information_before_passing_on_to_the_real_service.
</blockquote>
<blockquote>
It_would_be_very_useful_for_disseminators_to_be_able_to_use_the_value_of_a_datastream_or_disseminator_in_the_service_URL._This_would_allow:
- _"True"_disseminator_chaining,_without_forcing_each_object_to_contain_an_intermediate_redirect_datastream.
- _A_single_disseminator_could_direct_objects_to_different_services_depending_on_the_type_of_each_object.
- The_addresses_of"external"_services_could_be_placed_in_Fedora_objects._This_way,_if_I_had_a_Fedora_object_that_pointed_to_my_preferred_Saxon_location,_I_could_easily_redirect_all_disseminators_that_use_Saxon_to_another_machine._Or,_If_I_publish_my_disseminators_for_others_to_download,_they_only_need_to_create_one_object_that_points_to_their_copy_of_Saxon,_rather_than_needing_to_edit_each_individual_bmech_by_hand_to_point_it_at_their_Saxon.
</blockquote>
_Public_Demo_Fedora
Requested_by:_2006_Fedora_Conference_content_model_BOF_group
<blockquote>
It_would_be_nice_to_have_a_central_Fedora_repository_in_which_users_can_place_demonstration_objects_and_disseminators_for_others_to_view/download.It_is_likely_that_this_repository_would_require_a_mediator_to_prevent_submissions_of"spam"_objects.
</blockquote>
<blockquote>
<font_color="navy">At_OR07_a_'Disseminators_Working_Group'was_set_up._Part_of_their_brief_is_to_enable_this.</font>
</blockquote>
_Create_Relationships_among_Datastreams
Requested_by:_MMS_Team
<blockquote>
Please_consider_supporting_and_displaying_relationships_among_datastreams_in_a_compound_content_model.
</blockquote>
Requested_by:_MMS_Team
<blockquote>
Please_consider_supporting_DC_Qualified_and_other_standards_such_as_EAD,_LOM,_etc.
</blockquote>
_Support_for_externally_referenced_content
Requested_by:_Richard_Green
Many_Fedora_users_use_the_'external_referenced_content'model_to_manage_the_link_between_their_data_and_the_Fedora_object.The_Fedora_APIs_provide_all_the_management_you_need_for'managed_content'but_there_is_a_key_component_missing_for'external_referenced_content'.__It_would_be_very_useful_if_the_management_API_supported_a_call_or_calls_that_optionally_managed_the_external_dataload_alongside_the_object_itself.Thus_when_a_new_object_was_ingested_from_a_FOXML_file,_the_call(s)_would_also_move_the_data_file_from_its_local_position_to_the_appropriate_datastore.If_a_datastram_was_then_updated,_a_new_version_of_the_datafile_would_be_uploaded_as_well_as_the_new_instance_of_the_datastream-thus_extending_the_crucial_idea_of_versioning_to_external_dataloads_too.This_would_presumably_involve_timestampng_the_data_file_in_some_way._At_the_moment,_we_shall_have_to_provide_this_functionality_outside_Fedora_and_I_think_it_is_something_that_should_be_in...
_Fedora_Road_Map
Requested_by:_Christiaan_Kortekaas
<blockquote>
It_would_be_great_to_see_a_list_of_upcoming_features_in_the_future_versions_of_Fedora_somewhere_on_this_wiki._Even_better_would_be_if_the_developers_could_actively_indicate_what_features_out_of_the_list_are_complete_as_they_are_completed.
</blockquote>
_WebDAV_interface_to_repository
Requested_by:_Chris_Jackson
<blockquote>
It_would_be_very_helpful_to_have_a_WebDAV_and_DeltaV_interface_to_the_digital_objects_and_their_respective_metadata.Since_webdav_used_key:value_pairs_for_properties_or_metadata,_either_a_mapping_mechanism_would_need_to_be_worked_out_or,_more_simply,_a_single_property_would_return_an_representation_of_the_full_metadata_set._Some_mix_of_the_above_two_could_also_be_used,_with_dublin_core_values_mapped_to_webdav_properties_and_the_rest_served_as_an_object(plain_old_XML_or_RDF,_maybe).
The_intent_would_be_to_take_advantage_of_the_range_of_cross_platform_and_cross_language_client_code_and_standalone_client_applications._
</blockquote>
_Clean_up_the_Code!
Requested by: Mark Ricard
<blockquote>
Java code: The source code should be broken down into three distinct projects: server, common and client. Right now, there are so many interdependencies that you cannot create three separate projects and include only the server package in the server project, common package in a common project, etc. So you end up with one huge project - lots and lots of spaghetti code that needs to be fixed up. There are client classes referenced in server packages and server packages referenced in client packages. I would suggest creating three Eclipse-ish or Netbeans projects so others can contribute without having to continue with the madness!
</blockquote>
Requested by: Kostas Saidis
<blockquote>
It would be great if multi-lingual metadata were supported in a more fine-grained manner. Although there is no restriction in the language of DC values for example, there is no way to mix up multi-lingual DC metadata in the DC datastream and have FEDORA identify and/or treat them effectively.
</blockquote>
Fedora server module dependencies
Requested by: Kostas Saidis
<blockquote>
It's been a long time since I checked for this, so perhaps it has been fixed. The Fedora server implementation does not respect module dependencies, as expressed in fedora.fcfg. Modules are randomly loaded (using an iterator over a hash table's keys or something) without any guarantees that module A (depending on module B) will get initialized after B. In this effect, either module A does not get initialized appropriately or, depending on the error, the server itself fails to start.
</blockquote>
Simplified Object and Datastream Creation
Requested by: Matt Zumwalt
<blockquote>
Currently when creating a new object in Fedora, you have to create the skeleton FOXML for that object yourself and feed it into Fedora, despite the fact that the skeleton is basically the same for every new object you create. It would be really nice to have an alternate API method that creates an empty object for you based on a few optional parameters and returns the PID of that new object.
</blockquote>
<blockquote>
Also, there is the well known fact that Fedora requires you to use its upload servlet when creating new managed datastreams. I wish I could handle the uploads myself and give fedora a local (or network) file URL.
</blockquote>
Saxon 9 in Fedora 3.0
Requested by: Stuart Chalk
<blockquote>
I would like to be able to run XSLT 2.0 and Xqueries against Fedora objects using saxon. It would be great if saxon9b could be added to Fedora 3.0 release. If it will not be the default saxon version, could there be instructions on how to upgrade to version 9b included in the distribution?
</blockquote>