How are projects organized in the Data Exchange?

Credit and control goes to whom?

Q: What does "ownership" mean? Who should be an Owner?

Ownership means that you are control the data. Owners can be Users or Organizations. If you are a User-owner than only you can delete or update the project. If you are inside an organization that owns the project, then anyone in that organization with "contributor" or higher permissions can delete or update the project. For projects you have adequate permissions, when you hover over project properties, you will see an edit cursor available.  

Q: What does "sponsorship" mean? Who should be a Sponsor?

NOTE: Sponsors are implemented in the API but not yet complete in the UI. They will be arriving at some future date.

Sponsorship in the Data Exchange is simply a way of giving credit to parties that may be different than the ones that own/control the project. A project can have multiple sponsors and each sponsor must be either a user or an organization already in the system.

Q: What do UpdatedBY and CreatedBy mean?

UpdatedBy and CreatedBy are the users (never organizations) that performed the action using the CLI or the UI. These fields are automatically set by the system and cannot be changed.

Tags:

Tags are used to group projects that are thematically related. Tags are not stored inside the project XML and are used solely as a feature of the Data Exchange itself.

Metadata:

Metadata is used to add context to the data using key-value pairs (e.g.  a Key of Model Version to search by versus the specific value for that key of 3.1.1 below). Project Metadata can be visualized for any Riverscapes Project in the Data Exchange for the project in the metadata tab (e.g. below from this model)

Project Metadata can be "Hidden" which simply hides that key-value pair from view (hidden items can always be viewed though with the help of a radio button switch). Hidden metadata are good for machine-readable values that might be distracting or confusing for human meat brains.

Project Metadata can also have a type which gives software that reads it a hint on how to render/display it. Valid types (as of now) are:

  STRING
  GUID
  URL
  FILEPATH
  IMAGE
  VIDEO
  ISODATE
  TIMESTAMP
  FLOAT
  BOOLEAN
  INT
  RICHTEXT
  MARKDOWN
  JSON
  HIDDEN

Note: in the project.rs.xml, you will also find that there is layer and dataset specific metadata. This metadata is accessed in the Viewer by right clicking on a layer in the project tree and accessing.

Q: When should I use tags and when should I use Metadata?

Tags should be used when you want to group projects and relate them in a way that doesn't alter the project or the data. For example, I might group a bunch of Projects related to beaver or perhaps related to some external event like Hurricane Sandy.

Use Metadata to describe and give context to the project itself independent of other projects. For example, I might add metadata to a project to describe the model version, the date it was created, the author, the experimental conditions, the billing code, etc. Metadata changes get added to the XML so you should use metadata when you want that to travel with the project and be visible in external tools like QRV ARVRV etc.

Collections

Collections are used for grouping together small, manageable numbers of projects. Collections have Title, Summary, Hero Image, Description and Citation fields that can be used to describe the collection and it's purpose.

Q: When should I use a collection?

Collections should be used to group small numbers of projects together. It especially shines in cases where you want to group projects that are not easily searchable or categorizeable in other ways. For example, you can create a collection called "My Favorite Projects" and add all your favorite projects to it. 

Advantages to Collections

• Managed. The projects do not have to be related in any way to be added to a collection.

Disadvantages to Collections

• Collections have limits:
  • You can't add more than 1000 projects to a collection in a single operation.
  • Searching inside collections currently has a hard return maximum of 10000 projects.
  • Slow. Each project inside a collection creates 2 records: a dynamo record and a search record so adding a large number of projects to a collection can take a long time. Same goes for removing projects from a collection.
  • Tedious to manage. New projects need to be found and added to a collection by hand. Also there is not a good way to find projects that "should" be in a collection but aren't.

Saved Searches

Saved searches are used for creating views of projects that share a searchable set of criteria. Saved Searches have Title, Summary, Description and Citation fields that can be used to describe the collection and it's purpose.

NOTE: Saved searches are currently not implemented on the UI (as of Feb 2024). When they are this will start being relevant.

Saved searches aren't implemented yet but I need the functionality now! WHAT SHOULD I DO????

You can approximate the functionality of a saved search right now by copying the URL of the search you wish to saved and sharing that as a link, either in a markdown description of a record in the warehouse or just simply pasting it into an email.

Saved searches will hopefully be implemented soon so stay tuned...

Q: When should I use Saved searches?

Saved searches should be used to create views of large numbers of projects.

Advantages to Saved Searches

• Quick and lightweight. Since the projects belonging to a saved search are not managed or stored in the database, it is very quick to create a new saved search. This is especially useful when you have a large number of projects.
• Projects inside saved searches do not need to be managed. If you have a saved search that shows all projects with the tag "Beaver" and you add a new project with that tag, it will automatically show up in the saved search.
• Anything you can search for can become a view. This is an easy way to group projects with complex criteria (i.e. everything created in 2009 with the tag
• "Beaver" and the Metadata "ModelVersion" = "1.2.3")

Disadvantages to Saved Searches

• Unmanaged. It can be tricky to curate projects inside a saved-search. You need to add whatever criteria is necessary to the project before it appears or remove that criteria to make it go away. For complex searches this might be difficult and time consuming and it may be undesirable to change the projects just so they can be categorized in a certain way.

NOTE:  Most of above came from Matt Reimer in this discussion.