Re: Purpose and Extent

Owen, I understand your concerns at ending up with an array of
materialExtent property values.

Pragmatically I believe it is probably the best we can expect without
dipping into the realms of modelling over kill for something that often
will default to a string anyway.

As to that string, is it not a concatenation (a logical summing) of
separate extent statements, to which an array of QuantitativeValues is
logically similar.

~Richard.




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

On 31 July 2017 at 11:19, Jane Stevenson <Jane.Stevenson@jisc.ac.uk> wrote:

> Hi Owen,
>
> This works very well from our point of view, representing the UK archives
> that we do.
>
> As you’ll be aware, we would likely use the string, as very few archives
> catalogue in a structured way that shows unit and number. So having both
> options is ideal.
>
> >> 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).
>
> Yes, I take your point. But its not really relevant for us, as we’d ‘take
> the easy way out’!  But this is due to not being able to analyse accurately
> the data we have, and the inconsistencies within each repository.
>
> cheers,
> Jane.
>
>
>
>
> > On 21 Jul 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 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
> >>>
> >>
> >
>
> 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.
>