Re: Webby Data

Hi all.

Thanks to Phil for pointing out the BP for version identifiers etc. In
relation to the possible approach, it says "two URIs both resolve to this
document". Whilst this is true, it's worth considering (and pointing out in
the doc) that the durable URL (used for the doc throughout its entire
lifecycle) points to the resource that is the "document throughout its
entire lifecycle and is subject to change" whilst the URLs of versions
point to a resource that is immutable; a snapshot in time.

Makx- you say that it's difficult to apply this to datasets? I think not.
The important point is the durable URL always points to what the
_publisher_ decides is most appropriate (e.g. the most up to date
information set); this resource is mutable. The snapshots are immutable and
should be provided different URLs. From my perspective the URLs are point
to different resources - in some cases (e.g. the current version URL) they
refer to the same information set.

It's useful to be able to crosswalk between durable and versioned
resources. The Linked Data Registry provides a formal description of the
necessary relationships and talks about "VersionedThing".

You can use the properties to express the interrelationships. This would
then _imply_ that the resource is versioned. You don't explicitly need to
say that it's a VersionedThing.

That's all for now. Have to travel to work ...

Jeremy
On Sun, 11 Oct 2015 at 20:45, Makx Dekkers <mail@makxdekkers.com> wrote:

> Phil,
>
> I agree that a latest version link and timestamps work fine for documents
> in a publication workflow. Datasets are maybe a little bit more complex.
> For example, if you add a section to a document, I think that everybody
> would agree that it's a new version of the document. In the case of a
> dataset, you could have datasets that change over time but are still
> considered the same dataset. For example, a dataset recording today's
> weather may be extended every hour with an additional column, and it still
> would be today's weather.
>
> Makx.
>
>