W3C home > Mailing lists > Public > public-architypes@w3.org > April 2017

Re: Archive Collection and Archived Item

From: Richard Wallis <richard.wallis@dataliberate.com>
Date: Tue, 11 Apr 2017 13:59:47 +0100
Message-ID: <CAD47Kz4f4KEwj7B8CwsS+X3rDauTMW4YYL6m=AJwen4Qp3pOeg@mail.gmail.com>
To: Owen Stephens <owen@ostephens.com>
Cc: Giovanni Michetti <giovanni.michetti@ubc.ca>, Jane Stevenson <Jane.Stevenson@jisc.ac.uk>, public-architypes <public-architypes@w3.org>
Hi Owen,

I can see where that description when indirectly applied to an
ArchiveCollection might cause a certain amount of recursive confusion,

Have you an alternative suggestion?

~Richard.

Richard Wallis
Founder, Data Liberate
http://dataliberate.com
Linkedin: http://www.linkedin.com/in/richardwallis
Twitter: @rjw

On 11 April 2017 at 13:56, Owen Stephens <owen@ostephens.com> wrote:

> In terms of ArchivedItem, I really think changing the definition of
> ‘ArchivedItem’ so it no longer reads "An item in an archive collection.”
> would help clarify the situation. What’s the best way of moving this
> forward?
>
> Owen
>
> Owen Stephens
> Owen Stephens Consulting
> Web: http://www.ostephens.com
> Email: owen@ostephens.com
> Telephone: 0121 288 6936
>
> On 11 Apr 2017, at 13:45, Richard Wallis <richard.wallis@dataliberate.com>
> wrote:
>
> Hi Giovanni,
>
> Your view of the generic nature of ArchiveCollection (*Therefore, a
> fonds, a series, a subseries, a collection, a set of sparsed objects may
> all be subsumed under ArchiveCollection according to the its definition*.)
> is what I had in mind when I made the original proposal.
>
> Both Jane and you express confusion as to why ArchiveCollection is a
> sub-class of ArchivedItem, which is initially understandable.  The reason I
> proposed it that way is to make pragmatic use of the way Schema.org is
> constructed.
>
> ArchivedItem <http://archive.sdo-archive.appspot.com/ArchivedItem>, when
> added as an additionalType of any other Thing (CreativeWork, Product,
> whatever) effectively makes available properties to describe attributes of
> its membership in an archive (provenance, accessAndUse, itemCondition,
> location, transfer, etc.).   If the Type of Thing is unknown ArchivedItem
> could potentially be used as the only Schema Type.
>
> When looking to describe an ArchiveCollection, the majority of those
> properties would also be of use in its description.  To achieve this the
> proposal could have either individually added these properties to
> ArchivedCollction or, as I proposed, just make it a subtype of
> ArchiveCollection.
>
> ~Richard.
>
> Richard Wallis
> Founder, Data Liberate
> http://dataliberate.com
> Linkedin: http://www.linkedin.com/in/richardwallis
> Twitter: @rjw
>
> On 11 April 2017 at 13:06, Giovanni Michetti <giovanni.michetti@ubc.ca>
> wrote:
>
>> Hi Jane,
>>
>> I would stick to the definition of ArchiveCollection, which is "A
>> collection and/or archive of physical or digital items." (
>> http://archive.sdo-archive.appspot.com/ArchiveCollection).
>>
>> The Archival Extension doesn't define what an archive is (as a set of
>> objects--an archive is either an institution or an organization, according
>> to the definition of Archive). However, it is quite clear that the
>> definition of ArchiveCollection intends to cover any aggregation of items,
>> that is, the term 'archive' in the definition is used in a very generic
>> sense. Therefore, a fonds, a series, a subseries, a collection, a set of
>> sparsed objects may all be subsumed under ArchiveCollection according to
>> the its definition.
>>
>> Using a single class to identify any type of aggregations (including no
>> aggregation at all) is consistent with the most relevant archival
>> standards: ISAD uses "Unit of description" and EAD uses "Component".
>> Recently, ICA proposed a draft model (RiC) where they identified two
>> classes, Record and RecordSet (along with RecordComponent), which is a bit
>> different from the other models, yet is based on a single class identifying
>> any aggregation--that is, no need for fonds, series, etc.
>> We can discuss whether we need to distinguish between the single item and
>> its aggregations, or it is better to just stick to a simpler model, ie
>> "Component" like in EAD. However, going to your questions, I don't see any
>> problem in considering both your examples as being instantiated under
>> ArchiveCollection. The same for the properties.
>>
>> I don't understand very well why ArchiveCollection is a sub-class of
>> ArchivedItem in the Extension, so I share your doubts.
>>
>> As I wrote in some earlier message, I have many doubts about this model.
>> For this reason, I started investigating it further with some colleagues of
>> InterPARES Trust, in order to provide some systematic comments on the
>> Archival Extension. My aim is to share the comments in a month.
>>
>> Regards
>>
>> Giovanni
>>
>>
>>
>>
>> Il 11/04/2017 11:16, Jane Stevenson ha scritto:
>>
>>> Hi there,
>>>
>>> I had a huge email written as I was working this out, but I’ve tried my
>>> best to distill it down to one essential question…..
>>>
>>> There is a type ‘ArchiveCollection', which has ’super types’ of
>>> CreativeWork’ and ‘ArchivedItem’ with properties we can use to describe our
>>> thing(s).
>>>
>>> To take an example, let’s say I wanted to have schema.org markup
>>> attached to:
>>>
>>> A collection or ‘top level’ description: https://archiveshub.jisc.ac.uk
>>> /data/gb2607-ec/1-12
>>>
>>> A lower level description: https://archiveshub.jisc.ac.uk
>>> /data/gb2607-ec/1-12/ec/7
>>>
>>> All I know about these are that one is ‘top level’ so that there are no
>>> parent levels above it, but there may be child levels. The other is lower
>>> level, so it has at least one parent level.
>>>
>>> Can I just treat the lower level ’thing(s)' as type=ArchiveCollection?
>>> So, I can I use the properties from CreativeWork and ArchivedItem for both
>>> the top level and lower level group of stuff?
>>>
>>> I don’t want to distinguish between collection and item actually within
>>> the archive; I just want to apply schema.org markup using the
>>> appropriate types and associated properties.
>>>
>>> Richard defined Collection:
>>>
>>> “ArchiveCollection: The collection/grouping/assemblage of archived
>>> items. Descriptive properties reference the collection as a whole.”
>>>
>>> I want to separate this out from what archivist thing of as an archive
>>> collection, and treat it simply as a ‘group of things’ or even just one
>>> thing if that represents a stand-alone collection. Is this correct?
>>>
>>> The archive.schema.org defines ‘ArchivedItem’ as ‘an item in an archive
>>> collection’. But I thought it was a ‘type' that is applied to
>>> ArchiveCollection? I didn’t think it actually related to ‘item’ meaning a
>>> single thing.
>>>
>>> I think there is some confusion in the documentation between the term
>>> ‘ArchivedItem’, which I understand to be a type that can be applied to an
>>> ArchiveCollection, with properties of ‘archive-ness’,  and an actual item
>>> in a collection (and we don’t usually describe single items anyway). It
>>> maybe doesn’t help that the properties within ArchivedItem are ‘item’ -
>>> e.g. itemDescription, itemLocation, itemProvenance. Can I see them as
>>> archiveunitDescription, archiveunitLocation, archiveunitProvenance.
>>>
>>> NB - that’s why in EAD we use ‘unit’ and not anything like ‘item’  -
>>> because we can only know that it is a unit within a whole.
>>>
>>> cheers
>>> Jane
>>>
>>> Jisc is a registered charity (number 1149740) and a company limited by
>>> guarantee which is registered in England under Company No. 5747339, VAT No.
>>> GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill,
>>> Bristol, BS2 0JA. T 0203 697 5800.
>>>
>>> Jisc Services Limited is a wholly owned Jisc subsidiary and a company
>>> limited by guarantee which is registered in England under company number
>>> 2881024, VAT number GB 197 0632 86. The registered office is: One Castle
>>> Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
>>>
>>>
>>
>
>
Received on Tuesday, 11 April 2017 13:00:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 August 2018 13:28:59 UTC