- From: Richard Wallis <richard.wallis@dataliberate.com>
- Date: Tue, 11 Apr 2017 13:59:47 +0100
- 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>
- Message-ID: <CAD47Kz4f4KEwj7B8CwsS+X3rDauTMW4YYL6m=AJwen4Qp3pOeg@mail.gmail.com>
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