- From: Giovanni Michetti <giovanni.michetti@ubc.ca>
- Date: Tue, 11 Apr 2017 15:46:52 +0200
- To: Richard Wallis <richard.wallis@dataliberate.com>
- CC: Jane Stevenson <Jane.Stevenson@jisc.ac.uk>, public-architypes <public-architypes@w3.org>
Hi Richard, thank you for further explanation. I'm sorry, but I still don't get your point. ArchivedItem is "an item in an archival collection", so it is included in an archival collection by definition. Putting ArchiveCollection as a sub-class of ArchivedItem, means that ArchiveCollection is a type of ArchivedItem, which is not consistent with the definition of ArchiveCollection ("A collection and/or archive of physical or digital items"). From your words, I understand that your choice was driven by the need for specific properties. If that's the case, I wonder why we can't simply extend the properties of Thing, or find anyway some other solution. Giovanni Il 11/04/2017 14:45, Richard Wallis ha scritto: > 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 > <mailto: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 > <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 > <http://schema.org> markup attached to: > > A collection or ‘top level’ description: > https://archiveshub.jisc.ac.uk/data/gb2607-ec/1-12 > <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 > <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 > <http://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 <http://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:45:16 UTC