Add some more documentation on how objects will work. This creates

the blob object which is the base object that most people think of,
and changes the File Object to be more of a simple cache to a blob
object.  Still open if the file object is a simple cache object, or
references a specific blob object.

README.md

@@ -37,6 +37,12 @@ Look at adding units.
 
 These are the nodes that contain a majority of the data.
 
+### Common Properties
+
+The following properties are present on all (most?) objects:
+producer_ref	UUID of the producer that created this object.
+<signing>	Add signing info.
+
 ### MetaData Object
 
 Properties:
@@ -45,11 +51,13 @@ modified	date of last modification
 dc:<prop>	A [Dublin Core] property
 object_marking_refs	Imported from [STIX v2.0 Part 1]: Section 3.1
 granular_markings	Imported from [STIX v2.0 Part 1]: Section 3.1
+lang		RFC XXXX language of the properties.
+parent_ref	UUIDv4 of the parent MetaData Object.  Any properties on this object override the parent. (allow deletion via None/null?)  Any missing properties are passed through to the parent for resolution.
 
 Opinion Properties:
 qualityrating	On a scale from 1 (poor/terrible) to 5 (great/pristine), the subjective quality of the content.
 
-The base object will contain all the data associated w/ the file.  The base set of data is based upon the [Dublin Core] specification, as it provides a nice starting point, and will provide a good mapping to other systems out there.
+The base object will contain all the data associated w/ the file (object).  The base set of data is based upon the [Dublin Core] specification, as it provides a nice starting point, and will provide a good mapping to other systems out there.
 
 There may be a link to another MetaData object from which this one is derived.  If there is, all the meta data from the derived object (and the ones it derives from) must be included, except for the ones that have been marked deleted, or were overridden.  When a property is marked as opinion, it should not be inherited.  If the new author agrees with the opinion, then they have to restate the opinion in their object.
 
@@ -57,16 +65,37 @@ Custom properties must be preceded w/ a namespace.  The name space is name follo
 
 The link to the meta data object must include the version referenced, as the referenced object may change.  A three way merge may be needed when updating an object where the derived object has also been updated if the new information is wished to be used.
 
+If a property is imported from the blog itself, it is recommended to mark it as such via the granular marking, see X for more info on how to do this.
+
 Open Questions:  When meta data is "declassified", how do you maintain a link to the classified version?
 
+### Blob Object
+
+Properties:
+uuid		UUIDv4
+blobhash	Hash of the blob.  This needs to be indexed
+metadata_ref	UUID of the MetaData Object
+
+This is the main mapping object.  It maps a set of binary data to the MetaData object.  All the data must be stored on the MetaData object.  The reason it has a UUIDv4 is that this is your private mapping for the blog.  You could possibly have multiple mappings, but most people will only have one, and this also allows you to publish your mapping, and coexist w/ other producer's mappings.
+
 ### File Object
 
-A file object references a MetaData Object, and contains information about the file that the meta data object is associated with.
+Properties:
+uuid		UUIDv5  If the stats do not match, check hash, create a derivative blob object, possibly?
+modified	date of last modification of the object
+blobhash	Hash of the binary data.
+stat		Stats for the file, modified time, file size, used to detect when file has been changed/modified.
+
+A file object references a blob Object, and contains information about the file name in the file system associated w/ the blob.  This is used to speed up looking up blob objects.
 
 ### Container Object
 
 A container object references one or more File objects.  This is for representing containers such as zip or tar.gz files, but is also for BitTorrent hashes (event for single file torrents).
 
+### URL Object
+
+Similar to the File Object, but for web resources.
+
 ## Links
 
 These are the edges that connect the nodes.  For the most part they do not contain any data.
@@ -85,6 +114,9 @@ The two linked nodes, required to be File Objects, are equivalent.
 2. How to handle similar, but split meta data?  One person decides to make a simple meta data object for a scene from a movie, while another person makes a segment of that scene from the movie.  Should the segment object be a link between the two? or contain it's own proper data?  Some of this can be handled w/ an equivalent meta data object to link two meta datas as being the same.
 3. For quality, is this talking about the possible representation, or the actual "content"?  So, a VHS, or old analog over the air encoding may be crappy, but the movie content may be good.  We may want to do a multi layered approach (this is less than ideal due to complexities), where files can only link to info about that file, i.e. coding, format, resolution, and this meta data object links to one that is the actual content, i.e. movie w/ actors.  Or should this be done via overlay? i.e. someone creates a BluRay meta data object about a movie, and then the DVD overlays the DVD resolution and other info, w/ deleting properties that are not relevant.
 
+Ask cvoid:
+Should a file system reference point to the blob hash or the uuidv4 of the blog object?  blob hash requires a lookup, and maybe selection?  Maybe both?  To denote the selection.  Likely File Objects are going to be private, so internal optimization?  This will likely be different for URL objects as they are more public, where file system is often local only (unless on a shared, e.g. work, system).
+
 # Settled / Likely Closed
 
 1. Does a track of a CD deserve it's own "meta data" object?  Thinking yes, as the track may be played on radio, etc.  And the Album object can point to the tracks.  This also helps solve the compilation problem as the artists and other details are easier to represent separately.
@@ -125,3 +157,17 @@ New objects likely need to be validated in the immediately following block to he
 Likely there needs to be multiple "live" blocks that are intermingled.  This can be done via a simple LSFR + count, likely dependant upon number of updates and size and difficulty of validating objects.
 
 When updating, always check for n + 1 until n is not found.  When publishing, depending upon timeframe, select n where n is smallest but still means time parameter.
+
+
+----
+
+IPFS not sure if it has a final hash mapping system, but each object in IPFS may have different multihash depending upon how blog/list is broken out.
+
+Need a mapping system like:
+sha256:XXX -> ipfs:XLYkgq61DYaa8Nh3cq1U7rLinSa7dSHQ16x
+
+This could/should include multiple other items? like maybe block level hashing, though if there's an ipfs, that provides it..
+
+Reference Info:
+
+https://wiki.freedesktop.org/www/CommonExtendedAttributes/ Dublin Core reference by Freedesktop