feedback on PFIF 1.3

[Louiqa Raschid]

Ka-Ping - Sorry for not being active in this process. I have been swamped.
Here is some feedback. Good luck. Louiqa Raschid

Louiqa Raschid
Professor
Robert H. Smith School of Business and
Institute for Advanced Computer Studies and
Center for Bioinformatics and Computational Biology and
Department of Computer Science
University of Maryland

ACM Distinguished Scientist

================================================================================
Design principle #2
A more standard definition is that one should maintain the provenance of the data.
Provenance is more general than traceability.

Design principle #3
Identifying the source (original) repository is a good idea. Perhaps one could
also add a constraint that only the original repo can delete records. But the
current restriction that only the original repo can update the record seems to
prevent most useful manipulation of the data? For example it seems to prevent
another application from tagging the original record. But this is done in all
sorts of domains and there is no problem.

I suggest combining Design principle #5 and #6
We expect that there will be heterogeneity, inconsistency and conflict. While each
aggregator is free to address this challenge through schema mapping and matching and
instance matching there will be no attempt made to impose global solutions to
this problem via a single centralized matching and mapping repository.

Metadata about the record ...
Have you looked at the Dublin Core? They are well accepted. Why invent something else?
You should adopt or adapt or justify a new definition.
http://dublincore.org/documents/dces/

[Ka-Ping Yee]

Hello Louiqa,

Thanks for your feedback!

On Thu, Feb 10, 2011 at 22:08, Louiqa Raschid <lou...@umiacs.umd.edu> wrote:

====================

Design principle #3
Identifying the source (original) repository is a good idea. Perhaps one could
also add a constraint that only the original repo can delete records.  But the
current restriction that only the original repo can update the record seems to prevent most useful manipulation of the data?  For example it seems to prevent
another application from tagging the original record. But this is done in all
sorts of domains and there is no problem.

I agree that there should be no prohibition against any repository adding its own local tags to a record, only against changing the content within the record.  I've edited the text to clarify this.

 

Metadata about the record ...
Have you looked at the Dublin Core? They are well accepted. Why invent something else?
You should adopt or adapt or justify a new definition.
http://dublincore.org/documents/dces/

It turns out that PFIF needs elements that are more specialized than the Dublin Core elements.  For example, Dublin Core has simply "date" but we need to distinguish source_date, entry_date, and expiry_date; Dublin Core has "creator" but we need to distinguish author_name from author_email.  So, that's the justification behind the design.

—Ping
Google Crisis Response

[Tim Schwartz]

Re: Dublin Core - I would just add from experience with the
archiving/cataloging world that Dublin Core is almost always modified
to meet certain constraints of a project. It is a good starting point,
but almost all archives I have engaged with modify it, or use a
completely ground up metadata framework.

2cents
-tim