Use method other than metadata string filters for determining the organizations affiliationed with a data package
Right now when data is registered through an organization's skin, the metadata
for the entry is made to include a specific string, such as "UC Natural Reserve
System". When listing all the data packages from that organization, the current
method is to use that string as a filter. Unfortunately, if a data package
affiliated with an organization (such as the NRS) is submitted via a different
registry (such as ESA), the data package won't show up in the list of that
organization's data. Thus, a different approach is needed.
From Matt's email:
"The right way to do this would be to decouple the metadata entry from
the filter that controls whether a given entry shows up in the registry.
We've been experimenting with some ways to do this through 'semantic
annotations' that are maintained separately from the rest of the
metadata. This would allow us to retroactively label data packages with
annotations that could control which skin they show up in. It still
doesn't solve the maintenance problem (for each new registry skin that
we create, we need to annotate all past data packages that we want to
show up in the skin). I'm still not sure how to deal with that issue."
#3 Updated by Will Tyburczy over 13 years ago
(In reply to comment #2)
Another possible solution is to specify an attribute in the organization tag
which specifies if the document belongs to the registry of that organization.
Right now the skins don't allow users to specify more than one organization (aside from the one affiliated with the contact or creator). So dp's with multiple affiliations would still be a problem. Also, especially with regards to NCEAS, many people don't really like having NCEAS listed as an "owner" of their data, since usually that data was brought to NCEAS from outside sources.