various cleanups and clarifications...

README.md

@@ -4,12 +4,14 @@ The idea for medashare is both a standard, but also an implementation
 of defining and sharing meta data about files.  Some media contains the
 ability to embed meta data, e.g. mp3, some documents, video files, but
 not all files are able to convey the complete and rich information that
-may be desired.  This will allow you to identify files, and have
-external associated meta data with various files.
-
-The idea is also to be able to classify parts of the meta data as
-private (aka TLP:Red), such that the information will not be shared, so
-that you can mark files w/ your own tags and/or ratings, which will not
+may be desired.  Even if the file format has embedded data, it may not
+be modifiable, or even be desirable to modify the file to include the
+metadata.  This will allow you to identify files, and have external
+associated meta data with various files.
+
+It should be possible to classify parts of the meta data as private
+(aka TLP:Red), such that the information will not be shared, so that
+a person can mark files w/ your own tags and/or ratings, which will not
 be automatically shared.
 
 There will also be able to define derivative works by the standard.
@@ -29,7 +31,7 @@ associate general picture information w/ the raw image data (but none
 of the associated processing data that files like CR2 contains) so that
 the meta data is not lost.
 
-This work is inspired by my work on STIX, a Cyber Threat Intelligence
+This work is inspired by my work on [STIX], a Cyber Threat Intelligence
 standard, that has many similar requirements as meta data sharing.
 
 ## Goals / Use Cases
@@ -74,6 +76,16 @@ standard, that has many similar requirements as meta data sharing.
 Each object has a URN which uniquely describes it.  XXX copy from STIX
 URN proposal, which is simlar to the magnet proposal.
 
+Something similar to:
+```
+urn:medashare:uuid[--modifieddate]
+```
+
+And the URI version:
+```
+medashare:?xt=<urn>
+```
+
 ## Types
 
 Everything must have a type.  Not having well defined types can lead to
@@ -139,9 +151,10 @@ parent_refs	List of UUIDv4s of MetaData Object that overlay.  Any
 		passed through to the parent for resolution.  The
 		first/earliest object that has a property is used in
 		that objects later in the list are "hidden" by the
-		earlier objects.
+		earlier objects.  The modified date must be included
+		in this property.
 mimetype	The mime-type.  If the set of bytes is polymorphic,
-		there should be one for each "type".
+		there should be an object for each "type".
 uri		List of URI's where the file may be located.
 child_files	A dictionary where the keys are the file names and the
 		values are hash strings.  (One issue w/ using hashes is
@@ -160,25 +173,27 @@ 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.
+derived (via parent_refs).  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.
 
 Custom properties must be preceded w/ a namespace.  The name space is
 name followed by colon, as is demonstrated above w/ dc for [Dublin
-Core].
+Core].  For existing standards, please submit them for inclusion,
+otherwise a reverse dns name should be used, e.g.
+com.funkthat:property.
 
 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.
+If a property is imported from the file/object 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?
@@ -266,6 +281,7 @@ local only (unless on a shared, e.g. work, system).
 
 The [Dublin Core] standard is also noted by [RFC5013].
 
+[STIX] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cti
 [Dublin Core]: http://dublincore.org/documents/dces/
 [RFC5013]: https://tools.ietf.org/html/rfc5013
 [STIX v2.0 Part 1]: http://docs.oasis-open.org/cti/stix/v2.0/cs01/part1-stix-core/stix-v2.0-cs01-part1-stix-core.html