W3C home > Mailing lists > Public > public-architypes@w3.org > April 2017

Re: ArchiveCollection Properties

From: Richard Wallis <richard.wallis@dataliberate.com>
Date: Tue, 11 Apr 2017 16:21:50 +0100
Message-ID: <CAD47Kz7YRC0o=FwY-mODQu1ACLQf2iTwBs0o_Pr2CKVUcR3MwA@mail.gmail.com>
To: Jane Stevenson <Jane.Stevenson@jisc.ac.uk>
Cc: "public-architypes@w3.org" <public-architypes@w3.org>
Comments inline…

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

> Hi Richard,
>
> I am definitely keen now to progress this through to having some level of
> schema.org on the Hub, so good to be progressing the discussions. It is
> just a case of finding the time, but now we have our new service up and
> running, I think its a good time!
>
> >       • accessAndUse
> > I agree the term name may be a little confusing - maybe a rename to
> something like accessConditions
>
> Yes, I think that works, as it is ‘Conditions governing Access’  in
> ISAD(G).
>
If it was still felt to be needed I would suggest an appropriate name might
be ‘accessContions’


>
> > 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.
>
> Yes, but that’s partly the point - if it stays as ‘accessAndUse’ people
> may interpret it as ‘Conditions Governing Use’, which, as you say,  may be
> more appropriately described elsewhere.
>

I was thinking along the lines more of “By appointment only on weekdays”



>
> > • itemDescription
> > If it is the case that it is not common to provide a link to a
> descriptive document. This property could be dropped.
>
> A link to a whole description is common, but its rare to simply have a
> document with the descriptive content. I don’t think we’ve ever had an
> example of this. You might get something like an online PDF of the whole
> thing (title, date, extent, language, scope and content, etc)  but I’m not
> sure what is meant by "A document describing the item and/or its curation,
> history, etc.”
>

So what would such a link normally resolve to?


>
> > • 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.
>
> Ah, OK. So ‘partOf’ would be used to say: ArchiveCollection X is partOf
> the holdings of Institution Y.  I thought ItemLocation must mean the
> repository because it is related to ‘Place’.
>

This is where reusing properties *does* get confusing.  partOf would be
used to indicate that an item was part of a collection.  It may be used to
say that a Collection is part of a collection of collections.  More likely
that the institution would be identified as the provider of the collection.


> In the UK its not normal practice to make the actual physical location
> known. I’m not sure about practices in other countries, but its seen as a
> security issue so its usually internal only.
>

Hopefully our extension will be applicable to all sorts of archives from
web archives to personal collections.  As all properties in Schema.org are
optional, I would be inclined to keep it in for now.


> > • Identifier - since this proposal identifier has been added as a
> property to Thing in Schema.org so is available to all types.
>
> Ah good - it isn’t in the ArchiveCollection page at the mo, so I didn’t
> realise that.
>

http://schema.org/identifier

The current proposal is based on a previous version of Schema - I’ll bring
it up to date when we do any proposal updates.


>
> > • 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.
>
> OK, that’s good - I’ll take a look.
>
> > • 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
>
> The defintion of ‘creator’ in schema.org is:
>
> "The creator/author of this CreativeWork. This is the same as the Author
> property for CreativeWork.”
>
> I’m not sure, but just wondering if it is appropriate to use this for the
> person/organisation that accumulated the archive - they did ‘create’ the
> archive collection, but they didn’t necessarily ‘author' any of it.  I
> think for the sake of convenience the answer is that we should use it, but
> I was just raising it as a question to consider.
>

You would use creator and/or author as an when appropriate, I would suggest
a creator of an ArchiveCollection.


>
> cheers
> Jane
>
>
>
>
> > On 11 Apr 2017, at 14:29, Richard Wallis <richard.wallis@dataliberate.c
> om> wrote:
> >
> > 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.
> >
>
>
Received on Tuesday, 11 April 2017 15:22:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 August 2018 13:28:59 UTC