Re: ArchiveCollection Properties

Hi Jane,

Thanks for your thoughts, it is good that this conversation is starting to
move forward.

My thoughts on your thoughts:

   - accessAndUse
   I agree the term name may be a little confusing - maybe a rename to
   something like accessConditions.
   I would not link that with other concepts such as copyright, however.
   If the item was a CreativeWork of some type with copyright attached, a book
   for example, it would be defined as a schema:Book and a schema:ArchiveItem
   providing the relevant properties to describe the copyright.
   - itemDescription
   If it is the case that it is not common to provide a link to a
   descriptive document. This property could be dropped.
   - itemLocation
   This as proposed was intended to describe the current location of the
   item itself, which may or may not be the archive.  The relationship with
   the archive/responsible institution would be obtained via the
   ArchiveCollection it is defined as being partOf.
   - The reason for separation was that items may well move between
   locations for short or long periods but not necessarily coinciding with a
   change of ownership.
      - You may well be right however that such information would not
      necessarily be shared outside of the archive and hence is not needed in
      Schema.org
   - Information not covered
      - Identifier - since this proposal identifier has been added as a
      property to Thing in Schema.org so is available to all types.
      - Size/extent - these are properties that would be available from
      other type(s) associated with the description of an item, either
      schema:Product or a subtype of schema:CreativeWork.
      - Creator - would be available from the other type(s) associated with
      the description schema:CreativeWork or its subtypes. As you
describe.  I’m
      not clear what the difference is between the creator of an item and the
      archival creator (of an item) is.  Or are you talking about the
creator of
      the ArchiveCollection

~Richard.


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

On 11 April 2017 at 12:42, Jane Stevenson <Jane.Stevenson@jisc.ac.uk> wrote:

> Some thoughts about properties...
>
> * Properties that are currently proposed for ArchiveCollection *
>
> accessAndUse
>
> This brings together two concepts - information about access, which gives
> important information on whether the user can access the items - and
> information about use, which may refer to copyright, condition, or other
> things affecting how the materials can be used.  I think it may be
> confusing to bring these two together. I wondered what the thinking is
> here? Is it a case of trying to limit the number of properties? I would
> want to include Access Conditions in my schema.org markup, as I think
> this is something that is useful from the outset. information regarding use
> might be less important in this regard.
>
> itemDescription
>
> I don’t understand why this is defined as being a ‘document’. It is simply
> part of the description - there is generally no separate document. I’m not
> sure whether we should include the content of the description, as it can be
> very long, although it may be useful for discovery purposes.  Maybe this
> was defined as being a document because it would only be feasible to add a
> URL rather than the actual descriptive content?
>
> itemLocation
>
> This is intended to be the repository rather than actual physical
> location. It could be confusing to call it ‘location’ as the item may not
> be located at the repository’s address - it may be out-housed. But maybe
> that doesn’t matter as long as we know that this is defined as the
> responsible institution? In other words ‘Location’ actually means ‘Host’,
> or hosting institution.
>
> itemProvenance
> itemTransfer
>
> Not sure about separating these. Provenance tends to include the chain of
> ownership. Or does this mean the transfer to the repository, i.e. the
> immediate source of the acquisition? We don’t separate out transfers in a
> general sense, only a transfer into the repository, which might be the
> immediate source of acquisition.
>
> However, personally, I wouldn’t include this information within my
> implementation of schema.org, as I think it more properly lies within the
> description as a whole; I don’t see the argument for having it within
> schema.org
>
> * Information that is not covered within the ArchiveCollection property
> types *
>
> Identifier - I can’t see where the identifier would be added. Is the
> argument that it isn’t relevant to discoverability? That’s probably largely
> true, but its seen as core to the basic description. It would be odd to
> have things like provenance and not the actual reference for the archival
> unit being described.
>
> Size/extent - an indication of the volume of material is usually seen as
> core information. Again, maybe less important for discoverability, but more
> central than some of the other properties listed.
>
> * Creator *
>
> When we (the Locah project) were modelling in RDF we had the issue of the
> archival creator, and we decided that this was one instance where we had to
> create a new property, because archival creator is not author.
> It seems to come down to whether its better to use CreativeWork > Creator
> because it is a shared common concept, or whether its better to have a
> separate property, because the archival creator is a different concept.
>
> cheers,
> Jane
>
> Jisc is a registered charity (number 1149740) and a company limited by
> guarantee which is registered in England under Company No. 5747339, VAT No.
> GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill,
> Bristol, BS2 0JA. T 0203 697 5800.
>
> Jisc Services Limited is a wholly owned Jisc subsidiary and a company
> limited by guarantee which is registered in England under company number
> 2881024, VAT number GB 197 0632 86. The registered office is: One Castle
> Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
>