Re: Location in relation to archive contents

>From a proposer’s point of view I don’t see much disadvantage in going with
location, other than perhaps wishing to tweak the term description a
little.
e.g..
“The location of for example where the event is happening, an organization *or
thing* is located, or where an action takes place.”

For a community reviewing the proposal point of view, it may (only may)
raise some concerns about how it may effect or not its generic nature.
Concerns tat may be exacerbated by tweaking the description.
~Richard.

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

On 17 July 2017 at 12:14, Owen Stephens <owen@ostephens.com> wrote:

> Apart from the current limited defn of ‘location’ do you see any other
> advantages to going with ‘itemLocation’?
>
> I think the things in favour of ‘location’ are:
>
> Already exists
> Avoids problems of terminology (‘item’ again!)
>
> Owen
>
> Owen Stephens
> Owen Stephens Consulting
> Web: http://www.ostephens.com
> Email: owen@ostephens.com
> Telephone: 0121 288 6936
>
> On 17 Jul 2017, at 12:08, Richard Wallis <richard.wallis@dataliberate.com>
> wrote:
>
> 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.c
>>> om> 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_p
>>>> roposal 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 <http://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
>>>> <http://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 <http://schema.org/> group for consideration.
>>>> >>>>>>>
>>>> >>>>>>> A minor syntax point:  The convention within Schema.org
>>>> <http://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 <http://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.
>>>> >>>>>>>>
>>>> >>>>>>>
>>>> >>>>>>>
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>
>>>> >>>>
>>>> >>>
>>>> >>
>>>> >
>>>>
>>>>
>>>
>>>
>>
>
>