W3C home > Mailing lists > Public > public-architypes@w3.org > August 2015

Re: Archive as a collection of things

From: Richard Wallis <richard.wallis@dataliberate.com>
Date: Fri, 7 Aug 2015 19:27:12 +0100
Message-ID: <CAD47Kz4htz5UJLasEmaiJUAkg3UN7Q+Xa-DaXm2ScLYoOMGDdg@mail.gmail.com>
To: Giovanni Michetti <michetti@mail.ubc.ca>
Cc: "Young,Jeff (OR)" <jyoung@oclc.org>, Sarah Romkey <sromkey@artefactual.com>, public-architypes <public-architypes@w3.org>
Seems that we are moving towards of agreement albeit at differing levels of
detail. :-)

I suggest we let the harvesting of thoughts and opinions continue for a
while and then see if we have enough to shape up some examples to kick the
tyres on.


On 7 August 2015 at 18:29, Giovanni Michetti <michetti@mail.ubc.ca> wrote:

> Jeff,
> of course I agree, Events and Actions may help describing what happens to
> archival objects. However, I think you highlighted a relevant point here.
> According to the initial request from Richard, we have been asked to
> identify the relevant properties needed to describe archival objects. I
> started identifying some "areas", i.e, aspects that we consider relevant,
> because I took Richard's request as a sort of identification of users'
> needs rather than properties. In fact, you "translated" the need for
> information on the history of objects in a set of classes and properties.
> In other words, once a need is identified and accepted, we'll find a way to
> represent it--and there may be indeed different solutions.
> I think at this point is important to identify our needs, i.e. what we
> need to know about the objects. Once we agree on these needs, we may focus
> on the best way to represent them--either a new property, or a new class?
> either a specialization of a property or a new property? and so on.
> Anyway, the short reply is, I agree with you.
> Giovanni
> On 2015-08-07 6:04 PM, Young,Jeff (OR) wrote:
>> 1) yes, "owns" does half of the job, rather, part of it. Let me add
>>> something
>>> more, just to share knowledge and clarify the archival perspective.
>>> Archives are
>>> supposed to be repositories of authentic records. In order to guarantee
>>> and
>>> maintain authenticity we need to know what happens to objects from
>>> creation
>>> time till they come into our hands--any information gap may result in an
>>> "authenticity gap", since we may not be able to guarantee that records
>>> have
>>> not been tampered with, corrupted, misplaced etc. "What happens to
>>> objects"
>>> means that we need to know of any change of either the real obejcts
>>> (i.e.,
>>> change of format, amendments, compression...) or their context, that is,
>>> their
>>> surroundings, including owners, custodians or any other agent who had a
>>> role
>>> in maintaining the environment in which records are preserved.
>> It seems like http://schema.org/Event and/or http://schema.org/Action
>> could help track the history of an item. The connection back to the
>> ArchivalItem items could presumably be made using
>> http://schema.org/object.
>> 2) I'm not sure "hold" can be defined as a temporary ownership. For what I
>>> know the difference is legal. Objects may be held for decades by agent
>>> X, yet
>>> the property right may be held by agent Y. "To Hold" is about keeping
>>> stuff, "To
>>> Own" is about having a title of property on it.
>> This seems somewhat analogous to https://schema.org/TradeAction cases
>> where temporal/transient control can be expressed and attached to a thing,
>> again via http://schema.org/object.
>> Jeff
>> 3) Hence, the idea of enhancing OwnershipInfo doesn't seem to work to me,
>>> because it is anyway a value of property "own", which is a different
>>> thing from
>>> "hold/keep/whatever".
>>> In short, I would go for a different property. I understand your
>>> concerns, so
>>> maybe "Keep" may work. Otherwise, if we agree anyway that a class is
>>> needed,
>>> let's call it "Foo1" for the moment---we'll find the label later.
>>> re CreativeWorks:
>>> I agree with you, except that while it is true that "archivists identify
>>> that they
>>> have a need to describe a category [...] named Documents", it is not
>>> corrrect to
>>> state that archivists identify such a category as a CreativeWork--we are
>>> just
>>> discussing about it and see what the best solution is.
>>> Giovanni
>>> On 2015-08-07 3:20 PM, Richard Wallis wrote:
>>>> More good points and analysis - comments below...
>>>> ~Richard
>>>>      1) with regard to the two potential approaches there is a major
>>>>      issue: "owns" (ie "Products owned by the organization or person"
>>>>      [sic]) is not an adequate property for describing custody. When we
>>>>      talk about custodial history we are not necessarily talking about
>>>>      owning. Archives may be deposited, or borrowed (e.g., for an
>>>>      exhibition), so at a given time they may be possessed by an
>>>> archival
>>>>      institution, while being owned (i.e. possessed by right) by some
>>>>      other subject. The custodial history is the story of the custody,
>>>>      not the story of the owners. We need to trace it, because it
>>>>      provides fundamental information to assess authenticity.
>>>> Sounds like "owns" [with suitable expansion to include Things that are
>>>> not only Products] only does half the job, and we need a parallel
>>>> mechanism to describing temporary ownership or 'holding'.  One
>>>> possibility could be to enhance OwnershipInfo
>>>> <http://schema.org/OwnershipInfo> to be capable of describing
>>>> ownership of a temporary nature. Alternatively we could go for another
>>>> property to alongside owns. The name of 'holds' immediately comes to
>>>> mind but I fear it would not be acceptable to the the wider Schema.org
>>>> group due to alternative meanings in areas such as sport and medicine.
>>>>      2) with regard to archives as CreativeWorks, I agree with you: it
>>>>      cannot be argued that "a government document is not a type of
>>>>      CreativeWork", not because it is indeed, but because as a matter of
>>>>      fact CreativeWorks are not defined. It is strange though that we
>>>> can
>>>>      find email messages, datasets, books, and any sort of things in the
>>>>      CreativeWorks bucket, while documents and records have not been
>>>>      mentioned at all. I think first of all we should define a class for
>>>>      Document, since the bulk of an archives is made by documents after
>>>> all.
>>>> With the evolving nature of Schema.org it is not that surprising that
>>>> apparently obvious things are not yet represented in the vocabulary.
>>>> Types get into the vocabulary when a need is identified.  This is
>>>> exactly the process that we are engaged in here -- archivists identify
>>>> that they have a need to describe a category of CreativeWorks named
>>>> Documents and propose the creation of such a Type in an archives
>>>> extension or even potentially in the core vocabulary.
>>>> I have updated the Wiki Page
>>>> <https://www.w3.org/community/architypes/wiki/Main_Page> to reflect
>>>> this suggestion.
>>>>      Giovanni
>>>>      On 2015-08-07 1:04 AM, Richard Wallis wrote:
>>>>          Some good points Sarah - comments below...
>>>>               Two properties stick out to me that are not covered as far
>>>>          as I can
>>>>               tell in the generic Collection schema:
>>>>               1. Holding archives/institution: because archives are
>>>>          unique, it's
>>>>               important to record the institution that holds the
>>>> collection.
>>>>               Related to this point:
>>>>               2. Custodial history, or the archival history of the
>>>> collection
>>>>               before and during its custody in an institution. This is
>>>>          important
>>>>               to record for making presumptions of authenticity and
>>>>          understanding
>>>>               the limits to what the collection contains (e.g., half of
>>>>          it was
>>>>               lost in a fire, etc)
>>>>          There are a couple of potential approaches to these points.
>>>> Firstly
>>>>          coming at it from the holding organization's point of view:
>>>>             * Organization <http://schema.org/Organization> has an owns
>>>>               <http://schema.org/owns> property that has OwnershipInfo
>>>>               <http://schema.org/OwnershipInfo>  as one of the options
>>>> in its
>>>>               range. OwnershipInfo <http://schema.org/OwnershipInfo>
>>>> has some
>>>>               useful properties for capturing some of the things you
>>>> describe
>>>>               associated with ArchivesCollections it may hold.
>>>>             * Some of the current descriptions of these properties are
>>>> very
>>>>               Product focused, but recommending that an Organization can
>>>>               additionally own CreativeWorks (such as an
>>>>          ArchivesCollection) could
>>>>               well work.
>>>>          Secondly from the point of view of describing the same current
>>>> and
>>>>          historical information for a collection:
>>>>             * The OwnershipInfo Type could be enhanced to include the
>>>> owner
>>>>               Organization
>>>>             * The proposed ArchivesCollection could have an ownedBy
>>>>          property which
>>>>               would have Organization, Person, and OwnershipInfo in its
>>>> range
>>>>               Giovanni touched on this in the other thread covering
>>>> items in
>>>>               collections.
>>>>               Re: CreativeWork: in addition to the examples that you
>>>> raise
>>>>               Richard, there is a lot of content in archival collections
>>>>          which
>>>>               many would argue isn't "creative" in nature, such as data,
>>>>               governmental documents, etc. I would be glad to see us
>>>>          expand the
>>>>               hasPart idea beyond the scope of CreativeWork.
>>>>          So will I.  Not sure that in the generic Schema.org world that
>>>>          you could
>>>>          argue that a government document is not a type of
>>>> CreativeWork, but
>>>>          there are many other non-CreativeWork items that can be found
>>>> in
>>>>          Archives.
Received on Friday, 7 August 2015 18:27:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:57:12 UTC