- From: Richard Wallis <richard.wallis@dataliberate.com>
- Date: Mon, 17 Jul 2017 12:00:10 +0100
- To: Jane Stevenson <Jane.Stevenson@jisc.ac.uk>
- Cc: "owen@ostephens.com" <owen@ostephens.com>, public-architypes <public-architypes@w3.org>
- Message-ID: <CAD47Kz7x5B0rtTnht+U3VbUG_5YqDVjgeQ7veO-HUiQ=wpq7dg@mail.gmail.com>
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. ~Richard.
Received on Monday, 17 July 2017 11:00:53 UTC