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