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

ArchiveCollection Properties

From: Jane Stevenson <Jane.Stevenson@jisc.ac.uk>
Date: Tue, 11 Apr 2017 11:42:54 +0000
To: "public-architypes@w3.org" <public-architypes@w3.org>
Message-ID: <4E1735CD-95A7-4E3A-81EA-80688A134BBC@jisc.ac.uk>
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 11:43:29 UTC

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