Re: Purpose and Extent

Yes, that’s what I’m thinking.  I took a quick look at the UN/CEFACT Common Code and found a measurement for a linear foot (LF), which would be usually what we measure collections by, so we could easily use the unitCode property.  

I think we’d probably need a new type?  The definition of the TypeAndQuantityNode is “A structured value indicating the quantity, unit of measurement, and business function of goods included in a bundle offer.”  I don’t know what a bundle offer is, but it doesn’t seem to fit archives at all.

Elizabeth
___________________________
Elizabeth Russey Roke
Digital Archivist
Stuart A. Rose Manuscript, Archives, & Rare Book Library
404.727.2345 | erussey@emory.edu
 

 
 
"The Stuart A. Rose Manuscript, Archives, & Rare Book Library collects and connects stories of human experience, promotes access and learning, and offers opportunities for dialogue for all wise hearts who seek knowledge.”
 
Read the Rose Library blog: https://scholarblogs.emory.edu/marbl/

 
Like the Rose Library on Facebook:  https://www.facebook.com/emorymarbl

 
Follow the Rose Library on Twitter: https://twitter.com/EmoryRoseMARBL


On 7/18/17, 10:53 AM, "Owen Stephens" <owen@ostephens.com> wrote:

    Thanks Elizabeth,
    
    What do you think to having something like the existing TypeAndQuantityNode http://schema.org/TypeAndQuantityNode ?
    
    We could use this directly, or we could have a type “ArchiveExtentNode” with properties:
    
    unitCode [existing property]
    unitText [existing property]
    extentAmount [new property equivalent to amountOfThisGood]
    
    Owen
    
    Owen Stephens
    Owen Stephens Consulting
    Web: http://www.ostephens.com

    Email: owen@ostephens.com
    Telephone: 0121 288 6936
    
    > On 18 Jul 2017, at 15:43, Roke, Elizabeth Russey <erussey@emory.edu> wrote:
    > 
    > The conversation about extent has been helpful.
    > 
    > I agree with Jane that the value of extent is that it is a core descriptive element, intended to help humans determine the size of a collection.  But I keep coming back to the idea that if we make the model slightly more complex, a machine might be able to make use of it too.  I noticed that the book data type includes a property for number of pages, which seems similar to what we’re talking about with archival collections.  Perhaps we could generalize extent to include both extent and medium with the extent property containing an integer and the medium containing the unit for the extent property.  I can imagine an application being able to tie split collections together and determining where the prominent collection is held using these extent properties.
    > 
    > Elizabeth
    > 
    > ___________________________
    > Elizabeth Russey Roke
    > Digital Archivist
    > Stuart A. Rose Manuscript, Archives, & Rare Book Library
    > 404.727.2345 | erussey@emory.edu
    > 
    > 
    > 
    > 
    > "The Stuart A. Rose Manuscript, Archives, & Rare Book Library collects and connects stories of human experience, promotes access and learning, and offers opportunities for dialogue for all wise hearts who seek knowledge.”
    > 
    > Read the Rose Library blog: https://scholarblogs.emory.edu/marbl/

    > 
    > Like the Rose Library on Facebook:  https://www.facebook.com/emorymarbl

    > 
    > Follow the Rose Library on Twitter: https://twitter.com/EmoryRoseMARBL

    > 
    > On 7/17/17, 7:32 AM, "Jane Stevenson" <jane.stevenson@jisc.ac.uk> wrote:
    > 
    >> One (Schema.org) world is trying to apply more specific structure to things described on the web to help machines, albeit with increasing levels of AI capability, direct users to the Things they are trying to discover.
    >> 
    >> The other (archives) world is trying to capture the nuances of structure, provenance, and shared properties of the descriptions of the stuff they hold; for the better understanding of the humans viewing and searching through those descriptions.
    > 
    >> the separate discussions about a potential extent property highlight the same issues that current or traditional archive cataloging practice may not be ideally suited for transformation into structured web data (Schema.org).  We need to recognise that supporting what archives do now and what of that would be useful to share
    > 
    >    Yes, I agree with you, and that’s why I didn’t want to get into too many other areas of description. Maybe I’m too wedded to the importance of extent as core descriptive information, when really for the purposes of schema.org it is not really key.  For discoverability you want the about-ness and location primarily.  I would be OK to drop extent on that basis.
    > 
    >    cheers,
    >    Jane
    > 
    > 
    >> On 17 Jul 2017, at 12:00, Richard Wallis <richard.wallis@dataliberate.com> wrote:
    >> 
    >> 
    >> 
    >> On 17 July 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.
    >> 
    >> You raise some important questions here that other threads are now addressing the detail, however I thought it was worth commenting on the generalities too.
    >> 
    >> In proposing enhancements to Schema.org for archives and their contents we are trying to bridge two differing worlds.
    >> 
    >> One (Schema.org) world is trying to apply more specific structure to things described on the web to help machines, albeit with increasing levels of AI capability, direct users to the Things they are trying to discover.
    >> 
    >> The other (archives) world is trying to capture the nuances of structure, provenance, and shared properties of the descriptions of the stuff they hold; for the better understanding of the humans viewing and searching through those descriptions.  ( I know you can tell from the forgoing that I am not an archivist, but I hope you can get the gist of what I am trying to say ;-)
    >> 
    >> The purpose of including an itemLocation property in my model, was not specifically to indicate a different location for an item.  It was more  in recognition that the main purpose of web discovery is identify the Things, and related Things,  a user is looking for, and where they are physically or virtually located.  In archiving terms an item (If you have one, such as a physical Book or an AudioObject) can mostly be assumed to be located at the Archive organisation that holds the collection of which it isPartOf.  If possible (and if the data is available in the system publishing the Schema.org mark up) being specific would be helpful to the data consumers who may not follow that assumption.
    >> 
    >> Equally the separate discussions about a potential extent property highlight the same issues that current or traditional archive cataloging practice may not be ideally suited for transformation into structured web data (Schema.org).  We need to recognise that supporting what archives do now and what of that would be useful to share, whilst not precluding the use of more structurally specific description as it emerges.
    >> 
    >> Some key tests for each element of our proposals should be to ask how useful it would be in aiding discovery, and how will non-archivists consuming and interpreting our data understand what we are attempting to communicate by sharing it.
    >> 
    >> ~Richard.
    >> 
    >> 
    >> 
    >> 
    > 
    >    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.
    > 
    > 
    > 
    > ________________________________
    > 
    > This e-mail message (including any attachments) is for the sole use of
    > the intended recipient(s) and may contain confidential and privileged
    > information. If the reader of this message is not the intended
    > recipient, you are hereby notified that any dissemination, distribution
    > or copying of this message (including any attachments) is strictly
    > prohibited.
    > 
    > If you have received this message in error, please contact
    > the sender by reply e-mail message and destroy all copies of the
    > original message (including attachments).

Received on Tuesday, 18 July 2017 15:04:56 UTC