mvhub-dev team mailing list archive

[Dan MacNeil <dan@xxxxxxxxxx>]

Eventually, we want to share project and agency records across sites, 
even if the sites are run by completely different agencies.


I'm looking at Chris's good notes on data sharing:

http://wiki.thecsl.org/mediawiki/index.php/Subproject:Data_sharing


I have one specific question:

	Why does schema modification make RDF 'heavy' and rule it out?


And a couple observations:

	1) It might be good to create a top level design
            before settling on tech (XML, JSON, RDF)

	2)  Use cases are essential.

And a bunch of random thoughts:

Advantages of data sharing:
	1) one site updates, others benefit
	2) hassle users less for updates
	3) avoid duplicate / out of date records.

Political Disadvantages:
	1) Peer to Peer , who 'owns' data and glory

	2) There is only one other organization
	   interested in sharing data with us

	3) Trust, how do peers know that others don't break data

Technical Disadvantages
	1) uniquely identifying programs
		(agencies have EIN, as globally unique as a MAC address)
	
	2) google link juice, if same data appears across sites,
	   juice is diluted.  (cannonical tag across sites ?)

	3) duplicates (see #1)

	4) some sites have fields that other's lack.
		

Possible model:
   1) records are 'owned' by creator and 'published' to
      anyone who has defined a service area that includes
      that record.

  2) If a record is more than __ months out of date, it shows up
     in all sites list of records to update via phone call

  3) Once a site updates a record  it becomes 'theirs'

http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html

http://googlewebmastercentral.blogspot.com/2009/12/handling-legitimate-cross-domain.html