W3C home > Mailing lists > Public > public-architypes@w3.org > July 2017


From: Richard Wallis <richard.wallis@dataliberate.com>
Date: Mon, 17 Jul 2017 12:00:10 +0100
Message-ID: <CAD47Kz7x5B0rtTnht+U3VbUG_5YqDVjgeQ7veO-HUiQ=wpq7dg@mail.gmail.com>
To: Jane Stevenson <Jane.Stevenson@jisc.ac.uk>
Cc: "owen@ostephens.com" <owen@ostephens.com>, public-architypes <public-architypes@w3.org>
On 17 July 2017 at 09:15, Jane Stevenson <Jane.Stevenson@jisc.ac.uk> wrote:

> Hi all,
> This probably does work better in terms of my question - why not use
> ArchiveCollection for all units of description? As archivists don’t
> consistently catalogue to place the emphasis on one physical thing, I felt
> that trying to distinguish items was going to be problematic. If the main
> idea is that an item might be in a different location, I’m not sure that’s
> a good reason, because it is rare with archives, and I wouldn’t have
> thought people would start reflecting something being out on loan within
> their schema.org markup, as its not usually reflected in the catalogue
> anyway.
> So, my question is: why might it be important to clearly distinguish when
> something is one physical item as opposed to more than one physical item?
> And that comes down to the purpose of schema.org. I’m still not entirely
> clear what its potential might be. But I think some folks are thinking of
> using it for more detailed modelling, and I’m a bit concerned that would
> need us to model our whole environment, whereas I was thinking more of
> discoverability, and for that I’m not sure its so important….but even it if
> it, the catalogue data doesn’t really support it very well.

You raise some important questions here that other threads are now
addressing the detail, however I thought it was worth commenting on the
generalities too.

In proposing enhancements to Schema.org for archives and their contents we
are trying to bridge two differing worlds.

One (Schema.org) world is trying to apply more specific structure to things
described on the web to help machines, albeit with increasing levels of AI
capability, direct users to the Things they are trying to discover.

The other (archives) world is trying to capture the nuances of structure,
provenance, and shared properties of the descriptions of the stuff they
hold; for the better understanding of the humans viewing and searching
through those descriptions.  ( *I know you can tell from the forgoing that
I am not an archivist, but I hope you can get the gist of what I am trying
to say ;-)*

The purpose of including an itemLocation property in my model, was not
specifically to indicate a different location for an item.  It was more  in
recognition that the main purpose of web discovery is identify the Things,
and related Things,  a user is looking for, and where they are physically
or virtually located.  In archiving terms an item (If you have one, such as
a physical Book or an AudioObject) can mostly be assumed to be located at
the Archive organisation that holds the collection of which it isPartOf.
If possible (and if the data is available in the system publishing the
Schema.org mark up) being specific would be helpful to the data consumers
who may not follow that assumption.

Equally the separate discussions about a potential *extent* property
highlight the same issues that current or traditional archive cataloging
practice may not be ideally suited for transformation into structured web
data (Schema.org).  We need to recognise that supporting what archives do
now and what of that would be useful to share, whilst not precluding the
use of more structurally specific description as it emerges.

Some key tests for each element of our proposals should be to ask how
useful it would be in aiding discovery, and how will non-archivists
consuming and interpreting our data understand what we are attempting to
communicate by sharing it.

Received on Monday, 17 July 2017 11:00:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 August 2018 13:29:00 UTC