Re: Purpose and Extent

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 <http://dataliberate.com/>
> Linkedin: http://www.linkedin.com/in/richardwallis <http://www.linkedin.com/in/richardwallis>
> Twitter: @rjw
> 
> On 21 July 2017 at 18:31, Owen Stephens <owen@ostephens.com <mailto: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 <http://www.ostephens.com/>
> Email: owen@ostephens.com <mailto:owen@ostephens.com>
> Telephone: 0121 288 6936
> 
>> On 21 Jul 2017, at 17:20, Prom, Christopher John <prom@illinois.edu <mailto: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 <mailto:prom@illinois.edu>
>> 217 244 2052 <tel:(217)%20244-2052>
>>> On Jul 21, 2017, at 11:00 AM, Owen Stephens <owen@ostephens.com <mailto: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 <http://www.ostephens.com/>
>>> Email: owen@ostephens.com <mailto:owen@ostephens.com>
>>> Telephone: 0121 288 6936
>>> 
>>>> On 19 Jul 2017, at 14:38, Owen Stephens <owen@ostephens.com <mailto: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 <https://www.w3.org/community/architypes/wiki/Extent_proposal> very welcome
>>>> 
>>>> Owen
>>>> 
>>>> Owen Stephens
>>>> Owen Stephens Consulting
>>>> Web: http://www.ostephens.com <http://www.ostephens.com/>
>>>> Email: owen@ostephens.com <mailto:owen@ostephens.com>
>>>> Telephone: 0121 288 6936
>>>> 
>>>>> On 18 Jul 2017, at 18:09, Richard Wallis <richard.wallis@dataliberate.com <mailto: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 <http://dataliberate.com/>
>>>>> Linkedin: http://www.linkedin.com/in/richardwallis <http://www.linkedin.com/in/richardwallis>
>>>>> Twitter: @rjw
>>>>> 
>>>>> On 18 July 2017 at 08:45, Owen Stephens <owen@ostephens.com <mailto: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 <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 <http://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
>>>>> 
>>>> 
>>> 
>> 
> 
>