Re: Purpose and Extent

Sorry for being much slower at responding to this thread as I hoped to be.

This looks to be a good proposal for this particularly messy area.

I have added an extra section at the end of the page that references the
special case of the size of a collection (not just specific to archives).

Also fixed a couple of typos in the JSON-LD examples.

~Richard.

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

On 21 July 2017 at 18:31, Owen Stephens <owen@ostephens.com> wrote:

> Thanks Chris - this is really helpful - and good to hear!
>
> Owen
>
> Owen Stephens
> Owen Stephens Consulting
> Web: http://www.ostephens.com
> Email: owen@ostephens.com
> Telephone: 0121 288 6936
>
> On 21 Jul 2017, at 17:20, Prom, Christopher John <prom@illinois.edu>
> wrote:
>
> Sorry, I haven’t had much chance to follow all of the messages, and have
> been hoping to go back through them.
>
> In my experience, there is very little if any consistency in how archives
> treat the extent information, not locally, and certainly no across multiple
> repositories.   Software such as ArchivesSpace in the US allows multiple
> extent statements, and each statement has both a numerical value and unit
> of measure.  The other software that I am familiar with operates
> similarly.  So what you are proposing makes perfect sense and would mesh
> with that model.  I do think that users can have some difficulty
> interpreting these multiple extent statements, but that is a separate issue
> in my opinion, and would be best mitigated by whatever downstream service
> is representing the data.  (One weakness of current practice, which I don’t
> think it is possible to overcome, is that sometimes the multiple extent
> statements are different representations of the same materials, and
> sometimes they cover different materials.  In other words, we have no way
> to know if an archives is saying “5 folders” AND “200 photographs” or if
> they are saying “Five Folders” OR “200 Photographs”  But that is a problem
> in the underlying data structures.)
>
> Also, as you point out, it will be good to have a ‘backup’ method of just
> representing a string value, as you show in the second part of the proposal
> (Archive Component: Material Extent).  So, I think your proposal would
> cover almost all cases in US practice anyway.
>
>
> Chris Prom
> Assistant University Archivist
> Andrew S. G. Turyn Professor
> University of Illinois at Urbana-Champaign
>
> prom@illinois.edu
> 217 244 2052 <(217)%20244-2052>
>
> On Jul 21, 2017, at 11:00 AM, Owen Stephens <owen@ostephens.com> wrote:
>
> Not wishing to lose momentum (although I know it’s difficult to find the
> time to look at these things) I wonder if anyone has comments on this
> proposal?
>
> Owen
>
> Owen Stephens
> Owen Stephens Consulting
> Web: http://www.ostephens.com
> Email: owen@ostephens.com
> Telephone: 0121 288 6936
>
> On 19 Jul 2017, at 14:38, Owen Stephens <owen@ostephens.com> wrote:
>
> I’ve fleshed out the Extent proposal with a bit more detail now.
>
> The thing that I’m unhappy about in terms of modelling is that where we
> have multiple parts to the extent statement we end up with two properties
> on the object, which I think leaves the extent statement ambiguous. So for
> example for an extent statement of "1 folder; 5 design drawings” leads to
> two separate extent statements in the current proposal (unless you take the
> easy way out and jut dump it all in a single string).
>
> Comments and additions to https://www.w3.org/community/architypes/wiki/
> Extent_proposal very welcome
>
> Owen
>
> Owen Stephens
> Owen Stephens Consulting
> Web: http://www.ostephens.com
> Email: owen@ostephens.com
> Telephone: 0121 288 6936
>
> On 18 Jul 2017, at 18:09, Richard Wallis <richard.wallis@dataliberate.com>
> wrote:
>
> I wouldn’t be apposed to proposing a property that takes QuantitativeValue
> as an expected type to fit this requirement, if we could come up
> with some agreed guidelines and examples of how it would be used.
>
> There has been much discussion in Schema.org <http://schema.org/> around UN/CEFACT
> beyond its mention in QuantitativeValue description - the world of IoT
> are very focused on that too.  If we could leverage that interest to help
> our proposals all the better.
>
> Do we have the consistency in archive data to take this approach?
>
> I would expect to be challenged on a simple name of ‘extent’ for that
> property as either it is too specific to archives/libraries or; its broader
> understanding “the area covered by something” may cause confusion to
> wider adopters of Schema to be thinking in a spatialCoverage direction.  So
> we might need to be creative in naming, description and examples.
>
> Maybe we could loop in the library requirements at the same time….  Just
> a thought.
>
> ~Richard.
>
>
>
> Richard Wallis
> Founder, Data Liberate
> http://dataliberate.com
> Linkedin: http://www.linkedin.com/in/richardwallis
> Twitter: @rjw
>
> On 18 July 2017 at 08:45, Owen Stephens <owen@ostephens.com> wrote:
>
>> I agree that the definition doesn’t really seem to fit archives and their
>> content
>>
>> Doing a bit more looking around, perhaps a better starting point is
>> http://schema.org/QuantitativeValue. This is a generic Type allowing you
>> to specify a value (amount), and either unitCode or unitText
>> If you look further down the page you can see all the properties
>> currently in schema.org that can be expressed as a QuantitativeValue.
>> These include:
>>
>> height
>> width
>> depth
>> weight
>>
>> So just thinking out loud here - a couple of options:
>>
>> 1. Add new properties that represent the types of measure we want to
>> express (length, volume) - and let these take a QuantitativeValue
>> So you’d get something like:
>> schema:volume
>>         schema:QuantitativeValue
>>                 schema:unitText “boxes”
>>                 schema:value “3”
>>
>> schema:length
>>         schema:QuantitativeValue
>>                 schema:unitCode “LF”
>>                 schema:value “12”
>>
>> 2. Add a single new property of “extent” (or similar) which takes a
>> QuantitativeValue
>> schema:extent
>>         schema:QuantitativeValue
>>                 schema:unitText “boxes”
>>                 schema:value “3”
>>
>> schema:extent
>>         schema:QuantitativeValue
>>                 schema:unitCode “LF”
>>                 schema:value “12”
>>
>> Or we could implement both of course with ‘extent’ being a catchall
>>
>> 1. appeals as it avoids the library/archive use of ‘extent’ which is very
>> specific and different to what might be generally understood. On the
>> downside 1 requires us to agree on the set of measurements we need - and
>> some may not be obvious (e..g if you are measuring something in ‘sheets’ is
>> it a volume? or what?)
>>
>> Owen
>
>
>
>
>
>
>