- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Wed, 4 Nov 2015 15:34:40 -0800
- To: "public-socialweb@w3.org" <public-socialweb@w3.org>
- Message-ID: <CABevsUGGZqmVxReDofDW3dPe5wau0tDw6u2mPuKRE+396Tq23A@mail.gmail.com>
Again, sorry in advance to be both naive and pedantic, a terrible affliction. The `published` term is defined as "The date and time at which the object was published", and is used reasonably frequently in examples in -core. The intent in those examples appears to be along the lines of when the object was created or most recently modified, or when the activity that generated the object occurred. In Example 6 / Section 2.3, it seems like the timestamp for when the Like user activity occurred, which might be the time that the object was created, and that might be the same time that the object's serialization was first published. In a distributed hybrid online/offline those timestamps could be different between creating client and initial publishing server, and further very different between initial server and any harvesting/republishing server. Assuming an interaction model similar to RSS/Atom's, where the post is published and then aggregated by further feeds, I think in that case the published timestamp should remain the same? If that's true, then the definition could be modified to say something like: The date and time at which the object was first created or subsequently updated by its original publisher Then if a client wants to have a certain timestamp, it can add it for the server to make available. If not then the server can add it when it receives it, and it would then become set for other aggregating streams. I would propose not to be explicit about "object" vs "description of object" ;) #httprange14 Thoughts? Rob -- Rob Sanderson Information Standards Advocate Digital Library Systems and Services Stanford, CA 94305
Received on Wednesday, 4 November 2015 23:35:08 UTC