Re: Location in relation to archive contents

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/architypes/wiki/Initial_model_p
>> roposal
>> >>>>>
>> >>>>> 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.
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>>
>
>