Re: Purpose and Extent

I was/am going to reference this proposal on the Schema Bib Extend group
for comment.

~Richard.



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

On 28 July 2017 at 13:58, Owen Stephens <owen@ostephens.com> wrote:

> Thanks Richard,
>
> I’ve added a definition to the proposal - basically just re-using the
> wording from the EAD definition - whether this covers the library cases I’m
> not entirely sure - I think it does broadly, but I can see others
> disagreeing :)
> Do you think it is worth posting this over on the bibExtend group to get
> comments?
>
> Owen
>
>
> Owen Stephens
> Owen Stephens Consulting
> Web: http://www.ostephens.com
> Email: owen@ostephens.com
> Telephone: 0121 288 6936
>
> On 27 Jul 2017, at 17:26, Richard Wallis <richard.wallis@dataliberate.com>
> wrote:
>
> 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/communit
>> y/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
>>
>>
>>
>>
>>
>>
>>
>
>