Re: Documents that supersede others

[Versions] don't always form a linear sequence.  Cough BSD cough.

New versions may not supercede the old ones. Martha Yee's dissertation work
on near equivalents in versions of motion pictures is full of good examples
(being in charge of film cataloging at UCLA is a good way to get to
experience all the problem cases).
If someone wants to check out Blade Runner it's a matter of figuring out
which versions are good enough for what they want to do (which may vary
from time to time and person to person). Unicorns?

For technical documents or artifacts, version matching becomes quite
complex. For example, the semantics of a  schema.org markup on a page are
defined wrt the version of the schema that was published at the time the
markup was created (I think I have danbri on the  record as saying this :)

Then there are added complications; a document may be partially backwards
compatible, or it may clash.

If a page is describing a software package that depends on external
libraries, then the version of the library that one may want might be the
latest compatible version ; alternatively, if the software information
given is part of the description of a piece of computational science one
might want the exact version used (so that bug fixes do not change the
result).

OWL 2 ontology version management is a good example of not quite getting
things right.

Simon
On Nov 10, 2014 6:47 AM, <chaals@yandex-team.ru> wrote:

> 10.11.2014, 13:57, "Dave Caroline" <dave.thearchivist@gmail.com>:
> > I think an answer is a good old linked list, precedes doc, supersedes
> doc.
> > but should those be the creators terms or a fixed id or both?
> >
> > A searcher can land on any in the chain and find what he needs.
>
> Yeah, but our goal in schema.org is to help him land on the one most
> likely to be what he was looking for.
>
> The linked list is a good publication practice, and people who keep the
> historical archive available often do that. If we have terms in schema.org
> that match those, the linked list could be augmented to help searches get
> completed faster.
>
> cheers
>
> Chaals
>
> > I know I have an example that has yet to be catalogued in my
> > collection, it is a series of electrical handbooks for motorcycles by
> > Joseph Lucas, I have 19 in the series with what looks like some gaps
> > in the sequence.
> >
> > Dave Caroline
> >
> > On 09/11/2014, Karen Coyle <kcoyle@kcoyle.net> wrote:
> >>  Another common case is that of chasing down cited documents. I have a
> >>  report that cites a 1984 text on database design. To understand the
> >>  report and why it drew the conclusions it did, I would need to look at
> >>  that text. Gone.
> >>
> >>  Cited digital documents can be "pushed" to archiving services (such as
> >>  the Internet Archive) where they will be stored with a unique
> >>  identifier. Subsequent versions need to carry a link to at least the
> >>  immediately preceding version. That's the ideal case.
> >>
> >>  Note that in the case of hard copy items, libraries do not keep a
> record
> >>  of discarded books, so not only is the book gone, the record that the
> >>  book ever existed is also gone, other than to the extent that it has
> >>  been referenced by a still-extant document.
> >>
> >>  In other words, a huge bibliographic database like OCLC is not a
> >>  bibliography of published works, only of works currently held in
> libraries.
> >>
> >>  For some reason, this bothers me.
> >>
> >>  kc
> >>
> >>  On 11/9/14 12:45 AM, chaals@yandex-team.ru wrote:
> >>>  09.11.2014, 08:54, "Dave Caroline" <dave.thearchivist@gmail.com>:
> >>>>  Please dont forget the users who want a version of document to match
> >>>>  the item they have, I am thinking of a manual for an item, they also
> >>>>  go through various versions, sometimes with a model number change,
> >>>>  some times with a serial number/date range of device to doc relation.
> >>>  I started by facing a similar use case - drafts of specifications.
> >>>
> >>>  When you implemented against a particular draft it is useful to be
> able to
> >>>  find it. But the 80% case is "the latest version (perhaps with some
> status
> >>>  or characteristic)".
> >>>
> >>>  The behaviour I am trying to catch is attempts to remove the older
> >>>  versions from search results by marking them "don't index", while
> allowing
> >>>  for the 80% case to be simple - you get the one that superseded
> everything
> >>>  unless you want it to have some feature described that was removed, or
> >>>  something like that.
> >>>
> >>>  cheers
> >>>>  Note some information is missing from the original documents and
> items.
> >>>>
> >>>>  At the moment I have not added schema.org to my data because of this
> >>>>  sort of miss match.
> >>>>
> >>>>  Dave Caroline
> >>>>
> >>>>  An example manual search for one model number gets me 13 results in
> my
> >>>>  current collection.
> >>>>
> http://www.collection.archivist.info/searchv13.php?searchstr=telequipment+oscilloscope+s43
> >>>>
> >>>>  On 09/11/2014, chaals@yandex-team.ru <chaals@yandex-team.ru> wrote:
> >>>>>    Hi,
> >>>>>
> >>>>>    we already mark properties in schema with
> >>>>>  http://schema.org/supersededBy
> >>>>>    (whose range includes property and so far nothing else).
> >>>>>
> >>>>>    In various contexts entire documents do this, such as when they
> are
> >>>>>  being
> >>>>>    drafted, or when version X+1 replaces version X of something, or
> when
> >>>>>  a
> >>>>>    regulation is superseded by another, or when a set of rules for a
> >>>>>  sport is
> >>>>>    updated
> >>>>>
> >>>>>    The specific use case is a series of drafts that turn up pretty
> >>>>>  randomly in
> >>>>>    searches. For most purposes, the one anybody might want is the
> latest
> >>>>>    (admittedly there may be more than one form of "latest").
> >>>>>
> >>>>>    But I can think of a bunch of others...
> >>>>>
> >>>>>    cheers
> >>>>>
> >>>>>    Chaals
> >>>>>
> >>>>>    --
> >>>>>    Charles McCathie Nevile - web standards - CTO Office, Yandex
> >>>>>    chaals@yandex-team.ru - - - Find more at http://yandex.com
> >>>  --
> >>>  Charles McCathie Nevile - web standards - CTO Office, Yandex
> >>>  chaals@yandex-team.ru - - - Find more at http://yandex.com
> >>  --
> >>  Karen Coyle
> >>  kcoyle@kcoyle.net http://kcoyle.net
> >>  m: 1-510-435-8234
> >>  skype: kcoylenet/+1-510-984-3600
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> chaals@yandex-team.ru - - - Find more at http://yandex.com
>
>

Received on Monday, 10 November 2014 17:41:16 UTC