Re: Location in relation to archive contents

I could equally be convinced to try proposing the already established
*location* property and see what kickback we get, if any.

~Richard.

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

On 17 July 2017 at 12:06, Richard Wallis <richard.wallis@dataliberate.com>
wrote:

> You are right about contentLocation - that is used for instance to
> describe the city that a painting is featuring, not the gallery the wall of
> which it is hanging.
>
> I changed my proposal to use *ItemLocation* to match its parent type of
> *ArchiveItem*.  In the alternative proposal, agreeing on the type name
> should help in defining an *xxxxLocation* property.
>
> ~Richard
>
> Richard Wallis
> Founder, Data Liberate
> http://dataliberate.com
> Linkedin: http://www.linkedin.com/in/richardwallis
> Twitter: @rjw
>
> On 17 July 2017 at 11:25, Owen Stephens <owen@ostephens.com> wrote:
>
>> When I was writing up my proposal on the wiki last week I noticed an
>> issue with “Location” Initial proposal Richard had posted to start
>> discussion
>>
>> In the example markup in the Initial proposal (
>> https://www.w3.org/community/architypes/wiki/Initial_model_proposal) the
>> property schema:contentLocation is used to define the location of the
>> archive contents (i.e. where it is physically located).
>>
>> However, the ‘contentLocation’ property is currently defined in SDO as
>> "The location depicted or described in the content. For example, the
>> location in a photograph or painting.”, so it seems clear that this is not
>> the correct property.
>>
>> In my proposal I used the ‘location’ property instead. This is defined as
>> 'The location of for example where the event is happening, an
>> organization is located, or where an action takes place.’ - which is
>> better, but still doesn’t feel quite right.
>>
>> I think both proposals could and should be consistent in the way they
>> specify location of archive contents.
>> Is ‘location’ correct despite the slightly narrow definition?
>> Is there an existing alternative in SDO already?
>> Should we have a new property that is more specifically about the
>> location in relation to archive contents?
>>
>> Owen
>>
>> Owen Stephens
>> Owen Stephens Consulting
>> Web: http://www.ostephens.com
>> Email: owen@ostephens.com
>> Telephone: 0121 288 6936
>>
>> On 17 Jul 2017, at 11:13, Richard Wallis <richard.wallis@dataliberate.com>
>> wrote:
>>
>> The problem with such varied use, and probably the reason why there isn’t
>> such a property in Schema as yet, is those consuming the data have little
>> consistent idea as to what to do with it and how it might help
>> discoverability.   From that point of view, it might as well be just extra
>> description.
>>
>> From a collection point of view, knowing how many things it contains,
>> could be useful and I think we would could separate out that requirement
>> from the general discussion by a proposal for adding a *collectionSize*
>> property to the *Collection* Type.
>>
>> That does not solve many examples given which at best could only end up
>> populating some string property, for which we could propose an *extent* property.
>> That would need a really good description and examples.  Even then I
>> predict when proposing extensions to a community who’s goal is to provide
>> structured, and by implication more specific, data about things to aid
>> their discovery; it will be one of the first things to be challenged.
>>
>> ~Richard.
>>
>>
>>
>> Richard Wallis
>> Founder, Data Liberate
>> http://dataliberate.com
>> Linkedin: http://www.linkedin.com/in/richardwallis
>> Twitter: @rjw
>>
>> On 17 July 2017 at 10:58, Jane Stevenson <Jane.Stevenson@jisc.ac.uk>
>> wrote:
>>
>>> Extent in this case generally means (in reality) something non specific
>>> - so the most typical would be e.g. 10 boxes, 3 folders, 1 file, 5 volumes,
>>> 1 outsize box 3 standard boxes and 3 volumes. it can also be a bit more
>>> descriptive - one softbound leather volume, two loose sheets, one with a
>>> torn corner.
>>>
>>> I thought there would be a general property, but there doesn’t seem to
>>> be one already available to use.
>>>
>>> > We should try to be more precise when describing extent and use
>>> appropriate properties depending on the measure (e.g. if it is a measure of
>>> the size of the item, it might be appropriate to use ‘height’, ‘width’ &
>>> ‘depth' properties that aready exist in sdo)
>>>
>>> Very few units are described in this way in UK catalogues, although EAD
>>> does have ‘dimensions’ as a category for people to use, and cataloguing
>>> systems do provide fields for this type of thing, so we would take those
>>> values in if they were present, but they rarely are.
>>>
>>> I would say that realistically extent has to be some kind of very
>>> general measure of the size of the items, although people do sometimes
>>> blend this with type/format/dimensions/physical characteristics.
>>>
>>> cheers,
>>> Jane
>>>
>>>
>>>
>>>
>>>
>>> > On 17 Jul 2017, at 10:40, Owen Stephens <owen@ostephens.com> wrote:
>>> >
>>> > Jane has raised the question of adding an ‘extent’ property.
>>> >
>>> > Were there arguments against adding Extent previously? If so can
>>> anyone remind me of what they were? Two things spring to mind:
>>> >
>>> > a) Extent would apply to non-archive things and so ought to be added
>>> as a more general property (extent is also used for library materials at
>>> least)
>>> > b) We should try to be more precise when describing extent and use
>>> appropriate properties depending on the measure (e.g. if it is a measure of
>>> the size of the item, it might be appropriate to use ‘height’, ‘width’ &
>>> ‘depth' properties that aready exist in sdo)
>>> >
>>> > I think (a) is outside our immediate control. (b) is more of a
>>> practical issue I think - we could all agree that it would be better to be
>>> precise, but we know that this would be problematic given the metadata we
>>> start from in these descriptions.
>>> >
>>> > Are there other arguments about this?
>>> >
>>> > In terms of how an ‘extent’ property would be added to the current
>>> proposals:
>>> >
>>> > In https://www.w3.org/community/architypes/wiki/Alternative_1_m
>>> odel_proposal ‘extent’ would just get added as one of the new
>>> properties on ArchiveProperties (or ArchiveUnit) - so that’s
>>> straightforward.
>>> > In https://www.w3.org/community/architypes/wiki/Initial_model_proposal
>>> I think you’d need to add ‘extent’ to both ArchiveCollection and
>>> ArchiveItem types - not sure though and Richard probably the best person to
>>> comment
>>> >
>>> > Owen
>>> >
>>> > Owen Stephens
>>> > Owen Stephens Consulting
>>> > Web: http://www.ostephens.com
>>> > Email: owen@ostephens.com
>>> > Telephone: 0121 288 6936
>>> >
>>> >> On 17 Jul 2017, at 09:15, Jane Stevenson <Jane.Stevenson@jisc.ac.uk>
>>> wrote:
>>> >>
>>> >> Hi all,
>>> >>
>>> >> This probably does work better in terms of my question - why not use
>>> ArchiveCollection for all units of description? As archivists don’t
>>> consistently catalogue to place the emphasis on one physical thing, I felt
>>> that trying to distinguish items was going to be problematic. If the main
>>> idea is that an item might be in a different location, I’m not sure that’s
>>> a good reason, because it is rare with archives, and I wouldn’t have
>>> thought people would start reflecting something being out on loan within
>>> their schema.org markup, as its not usually reflected in the catalogue
>>> anyway.
>>> >>
>>> >> So, my question is: why might it be important to clearly distinguish
>>> when something is one physical item as opposed to more than one physical
>>> item? And that comes down to the purpose of schema.org. I’m still not
>>> entirely clear what its potential might be. But I think some folks are
>>> thinking of using it for more detailed modelling, and I’m a bit concerned
>>> that would need us to model our whole environment, whereas I was thinking
>>> more of discoverability, and for that I’m not sure its so important….but
>>> even it if it, the catalogue data doesn’t really support it very well.
>>> >>
>>> >> One option to actually specify level would be to…well, to specify
>>> level. To use a property for that such as ArchiveUnit:level.
>>> >>
>>> >> #An item in an archive (Note the definition of two types
>>> (schema:AudioObject, schema:ArchiveProperties).
>>> >> <https://archiveshub.jisc.ac.uk/data/gb71-thm/407/thm/407/8/3> a
>>> schema:AudioObject, schema:ArchiveProperties ;
>>> >>   schema:accessConditions "Please check with the Theatre and
>>> Performance enquiry team regarding access arrangements before making an
>>> appointment to listen to this item." ;
>>> >>   schema:dateCreated "1971-1972"^^schema:Date ;
>>> >>   schema:description "Sound recording of the first radio broadcast of
>>> Lines from My Grandfather's Forehead by Ronnie Barker and others. Duration:
>>> max 90 mins." ;
>>> >>   schema:about “Comedy”;
>>> >>   schema:duration "PT90M" ;
>>> >>   schema:inLanguage "EN" ;
>>> >>   schema:isPartOf "https://archiveshub.jisc.ac.u
>>> k/data/gb71-thm/407/thm/407/8" ;
>>> >>   schema:location "https://archiveshub.jisc.ac.u
>>> k/search/locations/eae30daa-1bf9-33d9-bf1c-7aeb220d2e76" ;
>>> >>   schema:name "Sound Recording of Lines from My Grandafther's
>>> Forehead (Radio)" ;
>>> >>   schema:playerType "Audio Cassette" ;
>>> >>   schema:identifier "GB 71 THM/407/8/3”
>>> >>   schema:level “item”
>>> >>
>>> >> Would that be a good idea? I’m still not sure how it helps in terms
>>> of what schema.org is there for.
>>> >>
>>> >> I would probably go with “ArchiveUnit” as the type rather than
>>> "ArchiveProperties", echoing EAD. I’m sure that was chosen precisely for
>>> the same reasons: it applies to any level of description.
>>> >>
>>> >> I would still like “extent” to be a property, as I still think that
>>> is core information.
>>> >>
>>> >> cheers
>>> >> Jane
>>> >>
>>> >>
>>> >> Jane Stevenson
>>> >> Archives Hub Service Manager
>>> >> jane.stevenson@jisc.ac.uk
>>> >> (Work days: Monday to Thursday)
>>> >>
>>> >> Tel: 0161 413 7555
>>> >> Web: archiveshub.jisc ac.uk
>>> >> Skype:  janestevenson
>>> >> Twitter: @archiveshub, @janestevenson
>>> >>
>>> >>
>>> >>
>>> >>> On 14 Jul 2017, at 15:46, Owen Stephens <owen@ostephens.com> wrote:
>>> >>>
>>> >>> OK - I’ve put up something on the wiki - I’ve not checked it through
>>> as carefully as I’d like but I wanted to get something up sooner rather
>>> than later - I think it captures the essence of the proposal even if there
>>> are errors or tweaks to be made.
>>> >>>
>>> >>> https://www.w3.org/community/architypes/wiki/Alternative_1_m
>>> odel_proposal
>>> >>>
>>> >>> Comments welcome.
>>> >>>
>>> >>> Owen
>>> >>>
>>> >>> Owen Stephens
>>> >>> Owen Stephens Consulting
>>> >>> Web: http://www.ostephens.com
>>> >>> Email: owen@ostephens.com
>>> >>> Telephone: 0121 288 6936
>>> >>>
>>> >>>> On 12 Jul 2017, at 14:22, Richard Wallis <
>>> richard.wallis@dataliberate.com> wrote:
>>> >>>>
>>> >>>> Yes Owen, lets see what that proposal might look like and compare
>>> the two.
>>> >>>>
>>> >>>> ~Richard.
>>> >>>>
>>> >>>> Richard Wallis
>>> >>>> Founder, Data Liberate
>>> >>>> http://dataliberate.com
>>> >>>> Linkedin: http://www.linkedin.com/in/richardwallis
>>> >>>> Twitter: @rjw
>>> >>>>
>>> >>>> On 12 July 2017 at 14:09, Owen Stephens <owen@ostephens.com> wrote:
>>> >>>> On 12 Jul 2017, at 13:08, Richard Wallis <
>>> richard.wallis@dataliberate.com> wrote:
>>> >>>>>
>>> >>>>> Hi Owen,
>>> >>>>>
>>> >>>>> Thanks for you input - never too late until the proposal is
>>> submitted and adopted :-)
>>> >>>>>
>>> >>>>> I feel that by focusing on Jane’s particular use case we are
>>> looking at an edge case, in Jane’s situation a nevertheless substantial
>>> one, but I want to be careful we don’t skew our proposal away from
>>> potentially broader generic cases.
>>> >>>>
>>> >>>> I don’t agree that this is an edge case - or at least I don’t think
>>> there is any evidence that it is. If this is the data that Archives Hub is
>>> getting, then I think it is reasonable to assume that this is the data that
>>> is available for many archives - and in that case many archives will be
>>> faced with the same issue of not knowing, on any automated basis, whether a
>>> particular description is a collection or an individual item
>>> >>>>
>>> >>>>> In describing archive collections and the things within them our
>>> objective is to make them more discoverable widely on the web.  I believe
>>> that in general non-archivists understand the concept of an Archive holding
>>> organisation which is responsible for collection(s) that contain things or
>>> items.  Reflecting that simplistic understanding was one of the starting
>>> points for the proposed model.
>>> >>>> I agree with this - I don’t think that anything I suggested went
>>> against this (or at least it wasn’t my intention)
>>> >>>>
>>> >>>>>
>>> >>>>> As to your particular points :
>>> >>>>>
>>> >>>>> The naming of a Type as ArchiveItem or ArchiveObject. Checking
>>> some online definitions I see that object and item are both synonyms of
>>> each other, however I still feel that the description of item (an
>>> individual article or unit, especially one that is part of a list,
>>> collection, or set.) is closer to what we are trying to express than that
>>> of object (a material thing that can be seen and touched)
>>> >>>> Fair enough - I was trying to find a term that didn’t suggest
>>> either an item or a collection - I obviously failed!
>>> >>>>
>>> >>>>>
>>> >>>>> Effectively merging the properties of ArchiveCollection and
>>> ArchiveItem. Using other types to define not only if it is a collection or
>>> not, but also what type of item it is, I Believe may be pushing the
>>> multi-type generic capabilities of Schema.org a little too far to be
>>> understandable to implementing archivists.  It has many similarities to my
>>> original proposal where ArchiveCollection was made a subtype of both
>>> Collection and ArchiveItem an approach, although logically correct, caused
>>> much discussion and confusion early on.
>>> >>>> I can see the potential to create confusion here, but I think this
>>> already exists in the current proposal which mixes two approaches to adding
>>> archive properties to a Thing. I think my proposal is simpler in that it
>>> adopts a single way of doing this. I’m not entirely happy with this (I was
>>> initially against the use of Intangible type) but I’d argue it is simpler
>>> as it reduces the number of new types and groups all the relevant
>>> properties in a single type.
>>> >>>>
>>> >>>>>
>>> >>>>> So going back to the proposal as it currently stands, it works
>>> well when you know what you are describing - an item or collection of items
>>> held by organisation.
>>> >>>>>
>>> >>>>> Where it is difficult is when you don’t know what you are
>>> describing.  What do you default to?  The two options being a collection
>>> (which would be wrong if it is for example an individual document) or; an
>>> item (which would be wrong if for example it was a folder containing
>>> several as yet to be described items).  Whichever of these are chosen it
>>> will be wrong some of the time.
>>> >>>>>
>>> >>>>> My thoughts are that it should be up to the describing
>>> organisation to decide, based on probabilities within their collection(s),
>>> as to which of these to choose.  Not ideal, but I believe preferential when
>>> compared with creating a fuzzy type that would work for either case but
>>> loose useful specificity when what is being described is known to be an
>>> individual item or a collection of items.
>>> >>>>
>>> >>>> While I don’t disagree its up to the describing organisation to
>>> decide (of course), it’s about the decision they are having to make.
>>> >>>> I’m proposing that the question of whether it is a Collection or
>>> not should be separate to whether the thing is in an Archive or not. At the
>>> moment this seems problematic as you have decide up front whether you want
>>> to use ArchiveCollection or ArchiveItem.
>>> >>>>
>>> >>>> The intent of my proposal was to separate out the question of
>>> ‘what’ it is, from the fact it is in an archive and therefore has a set of
>>> archive specific properties related to it.
>>> >>>>
>>> >>>> I’m inclined to write up a proposal using this approach on the wiki
>>> so I can be a bit more explicit and we can see how the approaches compare.
>>> Does this seem like a good way forward?
>>> >>>> Does anyone else have a comment or view on this?
>>> >>>>
>>> >>>> Owen
>>> >>>>
>>> >>>>
>>> >>>>>
>>> >>>>> ~Richard.
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> Richard Wallis
>>> >>>>> Founder, Data Liberate
>>> >>>>> http://dataliberate.com
>>> >>>>> Linkedin: http://www.linkedin.com/in/richardwallis
>>> >>>>> Twitter: @rjw
>>> >>>>>
>>> >>>>> On 12 July 2017 at 11:56, Owen Stephens <owen@ostephens.com>
>>> wrote:
>>> >>>>> Hi all,
>>> >>>>>
>>> >>>>> I’ve not had the time to contribute to this discussion so much,
>>> and it’s good to see some practical progress, but this latest point has
>>> brought me back to some slight unhappiness with the structure of the
>>> current proposal and the use of ArchiveItem. Apologies if this is either
>>> too late, or I’ve missed how the model has developed over the last few
>>> months. I’m looking at https://www.w3.org/community/a
>>> rchitypes/wiki/Initial_model_proposal
>>> >>>>>
>>> >>>>> As I understand it, the current proposal has ArchiveCollection as
>>> a subtype of Collection (which is a CreativeWork), while ArchiveItem is an
>>> intangible, and intended to be applied alongside other types (such as
>>> CreativeWork or Thing) to enable the addition of ArchiveItem properties to
>>> existing sdc types.
>>> >>>>>
>>> >>>>> The case that Jane has highlighted here is that it is unknown
>>> whether what we are looking at is a Collection or a specific Item.
>>> >>>>>
>>> >>>>> In this case, giving something that maybe a collection or maybe an
>>> item the type ArchiveCollection, seems wrong - it suggests a level of
>>> specificity we don’t know.
>>> >>>>> Also it seems to me that giving it a type ArchiveItem doesn’t
>>> imply it is actually a specific item - because ArchiveItem can be applied
>>> alongside other types (presumably including ArchiveCollection).
>>> >>>>>
>>> >>>>> So it would make more sense to me in this case to state that the
>>> thing is a Thing or CreativeWork, with an additional type of ArchiveItem -
>>> this doesn’t imply it is either a single item or a collection, it would
>>> leave this open to question - which seems to me to reflect the reality of
>>> the situation.
>>> >>>>>
>>> >>>>> Trying to draw this up into the modelling of archives in scd, the
>>> question it brings me to - is what is the advantage of splitting archival
>>> properties between ArchiveCollection and ArchiveItem? Why not bundle all
>>> the properties (there aren’t that many) into a single type based on
>>> intangible (taking the current ArchiveItem approach) - I’ll call it
>>> ‘ArchiveObject’ for now. When you know you have a Collection you apply type
>>> of Collection and ArchiveObject, and when you have a CreativeWork you apply
>>> type of CreativeWork and ArchiveObject etc.
>>> >>>>>
>>> >>>>> At the moment applying ArchiveCollection when you aren’t sure
>>> whether it is actually a Collection seems wrong to me. If there is any
>>> ambiguity then I think you can apply ArchiveItem (you know it is in an
>>> Archive) but you can’t assert Collection.
>>> >>>>>
>>> >>>>> Owen
>>> >>>>>
>>> >>>>> Owen Stephens
>>> >>>>> Owen Stephens Consulting
>>> >>>>> Web: http://www.ostephens.com
>>> >>>>> Email: owen@ostephens.com
>>> >>>>> Telephone: 0121 288 6936
>>> >>>>>
>>> >>>>>> On 12 Jul 2017, at 11:29, Jane Stevenson <
>>> Jane.Stevenson@jisc.ac.uk> wrote:
>>> >>>>>>
>>> >>>>>> Hi Richard,
>>> >>>>>>
>>> >>>>>> Yes, we are an awkward case! But at least we then bring benefits
>>> to over 300 repositories when we implement schema.org.
>>> >>>>>>
>>> >>>>>>> As to your A/B decision, I can only suggest from a non archivist
>>> point of view, but if something has already been identified in someway as
>>> an item or piece, it would be worth reflecting that in the description
>>> shared with the web (using the ArchiveItem type), then defaulting, in your
>>> case, to ArchiveCollection where this is not known.
>>> >>>>>>>
>>> >>>>>> Perfect - I was going to go with that, as I’m thinking be
>>> accurate where you can be accurate.
>>> >>>>>>
>>> >>>>>>> A minor syntax point:  The convention within Schema.org is for
>>> the names of Types to begin with an uppercase letter (Archive,
>>> ArchiveCollection, ArchiveItem)  and properties with a lowercase
>>> (ItemLocation, holdingArchive, accessConditions, etc.).   I know we are
>>> only in discussion mode, but looking back on this documentation it can be
>>> confusing for some if we don’t follow these conventions here as well as in
>>> the type definitions etc.
>>> >>>>>>
>>> >>>>>> Thanks. I may have been a bit inconsistent with this….but we’ll
>>> ensure we implement it correctly.
>>> >>>>>>
>>> >>>>>> OK….we’ll crack on then.
>>> >>>>>>
>>> >>>>>> Thanks to all - the discussion has been really useful.
>>> >>>>>>
>>> >>>>>> cheers,
>>> >>>>>> Jane
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> Jane Stevenson
>>> >>>>>> Archives Hub Service Manager
>>> >>>>>> jane.stevenson@jisc.ac.uk
>>> >>>>>> (Work days: Monday to Thursday)
>>> >>>>>>
>>> >>>>>> Tel: 0161 413 7555
>>> >>>>>> Web: archiveshub.jisc ac.uk
>>> >>>>>> Skype:  janestevenson
>>> >>>>>> Twitter: @archiveshub, @janestevenson
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>> On 12 Jul 2017, at 10:20, Richard Wallis <
>>> richard.wallis@dataliberate.com> wrote:
>>> >>>>>>>
>>> >>>>>>> Thanks Jane for your insight into the issues surrounding this
>>> within Archives Hub.  As effectively an aggregator of archives this
>>> provides a test of the model at one end of the spectrum of use cases we are
>>> looking to satisfy.
>>> >>>>>>>
>>> >>>>>>> As you say, from the information you are provided with you may
>>> not know if something being described is a collection or a single item.
>>> Also it is unlikely that you would know if a single item is located with
>>> the rest of the collection or not.
>>> >>>>>>>
>>> >>>>>>> Those responsible for other individual archives may well be very
>>> clear on these things for their collections.  Hopefully we are in a
>>> position to satisfy the broad spectrum of use cases with this proposal.
>>> >>>>>>>
>>> >>>>>>> As to your A/B decision, I can only suggest from a non archivist
>>> point of view, but if something has already been identified in someway as
>>> an item or piece, it would be worth reflecting that in the description
>>> shared with the web (using the ArchiveItem type), then defaulting, in your
>>> case, to ArchiveCollection where this is not known.
>>> >>>>>>>
>>> >>>>>>> If there are no further discussion points from the group, I
>>> intend in the next couple of weeks to forward this proposal to the
>>> Schema.org group for consideration.
>>> >>>>>>>
>>> >>>>>>> A minor syntax point:  The convention within Schema.org is for
>>> the names of Types to begin with an uppercase letter (Archive,
>>> ArchiveCollection, ArchiveItem)  and properties with a lowercase
>>> (ItemLocation, holdingArchive, accessConditions, etc.).   I know we are
>>> only in discussion mode, but looking back on this documentation it can be
>>> confusing for some if we don’t follow these conventions here as well as in
>>> the type definitions etc.
>>> >>>>>>>
>>> >>>>>>> ~Richard.
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> Richard Wallis
>>> >>>>>>> Founder, Data Liberate
>>> >>>>>>> http://dataliberate.com
>>> >>>>>>> Linkedin: http://www.linkedin.com/in/richardwallis
>>> >>>>>>> Twitter: @rjw
>>> >>>>>>>
>>> >>>>>>> On 12 July 2017 at 09:36, Jane Stevenson <
>>> Jane.Stevenson@jisc.ac.uk> wrote:
>>> >>>>>>> Hi Richard,
>>> >>>>>>>
>>> >>>>>>>> It would work to describe a collection of one or more things.
>>> However, if you have a known physical item (book, article, photograph, etc)
>>> or file (video, audio, image, web page, etc.) why would you not describe it
>>> as such?
>>> >>>>>>>
>>> >>>>>>> This is the nub of the matter….it is because we won’t always
>>> know. We can definitely decide that if the level is described as “item” we
>>> apply the archiveItem type. But (1) levels are not always given values -
>>> although on the Hub we do ask for this, but in general, within EAD, values
>>> are not mandatory (2) You can have a level that is a sub-series, or a
>>> folder or a file that is effectively one physical item, but the level value
>>> does not identify this. Archivists will describe ‘one folder’ but it may
>>> have one item in it.  Is something described as ‘one folder’ an item?
>>> Should ‘one box’ always be treated as a collection of items, although it
>>> may only have one item in it , e.g. an account book is a sub-series in one
>>> box.
>>> >>>>>>>
>>> >>>>>>> It is maybe possible for an individual repository to sort out
>>> single item descriptions  from ‘more than one item’ descriptions, but its
>>> not possible for us to do that in an automated way across all our data.
>>> People aren’t consistent enough with cataloguing for that, and to be fair,
>>> the standards have never emphasised the importance of distinguishing one
>>> physical item in this way.
>>> >>>>>>>
>>> >>>>>>>> This comes back to describing information about an individual
>>> item.  Potentially the ArchiveCollection the item is part of could be held
>>> by an organisation (Archive), yet an individual item could be located, on
>>> extended loan for example, at a different location.
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> OK. I get the logic. It is just quite rare for that to happen,
>>> unlike museums. And if it was temporarily elsewhere, we wouldn’t know.
>>> Something on loan would not be flagged as such in the description. But
>>> that’s OK - we would always just use the repository as the holding
>>> institution, so itemLocation, if we use it, would always have the same
>>> value as holdingArchive. If an item was on loan it simply wouldn’t show up
>>> in our schema.org data.  I don’t think that matters. As you say, its
>>> optional anyway.
>>> >>>>>>>
>>> >>>>>>> I think we’re ready to go now. I just have to decide on either
>>> >>>>>>>
>>> >>>>>>> A. Always use archiveCollection, including for items, because we
>>> can’t distinguish all items anyway
>>> >>>>>>> B. use archiveItem where we have a level value of “item” or
>>> “piece”, which will give us a majority of items (my estimate is that we
>>> would get something like 70% of single entities this way), but it will be
>>> the case that a fair number of items won’t be described as items because
>>> they don’t have that level value, even if they are single physical
>>> entities, so they will be single physical items but described as type
>>> archiveCollection.
>>> >>>>>>>
>>> >>>>>>> cheers,
>>> >>>>>>> Jane.
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> Jane Stevenson
>>> >>>>>>> Archives Hub Service Manager
>>> >>>>>>> jane.stevenson@jisc.ac.uk
>>> >>>>>>> (Work days: Monday to Thursday)
>>> >>>>>>>
>>> >>>>>>> Tel: 0161 413 7555
>>> >>>>>>> Web: archiveshub.jisc ac.uk
>>> >>>>>>> Skype:  janestevenson
>>> >>>>>>> Twitter: @archiveshub, @janestevenson
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>> On 11 Jul 2017, at 17:26, Richard Wallis <
>>> richard.wallis@dataliberate.com> wrote:
>>> >>>>>>>>
>>> >>>>>>>> Hi Jane,
>>> >>>>>>>>
>>> >>>>>>>> Sorry for being slow in responding.
>>> >>>>>>>>
>>> >>>>>>>> Answers inline.
>>> >>>>>>>>
>>> >>>>>>>> ~Richard.
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> On 3 July 2017 at 07:48, Jane Stevenson <
>>> Jane.Stevenson@jisc.ac.uk> wrote:
>>> >>>>>>>> Hi Richard and everyone,
>>> >>>>>>>>
>>> >>>>>>>> If I decided to only use #archiveCollection for all of the
>>> units of description, would that work?  We don’t necessarily know if units
>>> described are single items or more than one item anyway, and it seems to me
>>> we can effectively describe each unit with the properties now provided,
>>> which is the main thing. So my question is, why would I need to use
>>> #archiveItem?
>>> >>>>>>>>
>>> >>>>>>>> It would work to describe a collection of one or more things.
>>> However, if you have a known physical item (book, article, photograph, etc)
>>> or file (video, audio, image, web page, etc.) why would you not describe it
>>> as such?
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> Just one more question…. we have properties archiveHeld and
>>> holdingArchive, and we also have itemLocation. How is itemLocation
>>> different from holdingArchive? In the example, for Ronnie Barker,
>>> itemLocation is given as the V&A Theatre & Performance Archive (URL). But
>>> surely the property of holdingArchive would do just as well.
>>> >>>>>>>>
>>> >>>>>>>> This comes back to describing information about an individual
>>> item.  Potentially the ArchiveCollection the item is part of could be held
>>> by an organisation (Archive), yet an individual item could be located, on
>>> extended loan for example, at a different location.
>>> >>>>>>>>
>>> >>>>>>>> All properties within Schema.org are optional, so you probably
>>> would only provide an itemLocation when an item is located separate from
>>> the holdingArchive of the ArchiveCollection of which it is part.
>>> >>>>>>>>
>>> >>>>>>>> ~Richard.
>>> >>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>> cheers
>>> >>>>>>>> Jane
>>> >>>>>>>>
>>> >>>>>>>> Jane Stevenson
>>> >>>>>>>> Archives Hub Service Manager
>>> >>>>>>>> jane.stevenson@jisc.ac.uk
>>> >>>>>>>>
>>> >>>>>>>> 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.
>>> >>>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>
>>> >>
>>> >
>>>
>>>
>>
>>
>