Re: Purpose and Extent

A good wish!

I’ve just landed home after a quick visit to California (if there is such a
thing!) - took a quick glance at what you are proposing and it looked like
something definitely pursuing.  Will take a better look over the next
couple of days and respond.

~Richard.

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

On 21 July 2017 at 17:00, 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
>
>
>
>
>