W3C home > Mailing lists > Public > public-architypes@w3.org > August 2015

RE: Archive as a collection of things

From: Young,Jeff (OR) <jyoung@oclc.org>
Date: Fri, 7 Aug 2015 19:29:11 +0000
To: Richard Wallis <richard.wallis@dataliberate.com>, Giovanni Michetti <michetti@mail.ubc.ca>
CC: Sarah Romkey <sromkey@artefactual.com>, public-architypes <public-architypes@w3.org>
Message-ID: <BLUPR06MB129A8667BCFEC8B27FA1440AD730@BLUPR06MB129.namprd06.prod.outlook.com>
Here’s a glossary that may help with the idea harvesting:

http://www2.archivists.org/glossary/terms


Also, this diagram illustrating the BNB project is pre-Schema.org, but it helped me wrap my head around key relationships in the bibliographic space.

http://www.bl.uk/bibliographic/pdfs/bldatamodelbook.pdf


Jeff

From: Richard Wallis [mailto:richard.wallis@dataliberate.com]
Sent: Friday, August 07, 2015 2:27 PM
To: Giovanni Michetti
Cc: Young,Jeff (OR); Sarah Romkey; public-architypes
Subject: Re: Archive as a collection of things

Seems that we are moving towards of agreement albeit at differing levels of detail. :-)

I suggest we let the harvesting of thoughts and opinions continue for a while and then see if we have enough to shape up some examples to kick the tyres on.

~Richard

On 7 August 2015 at 18:29, Giovanni Michetti <michetti@mail.ubc.ca<mailto:michetti@mail.ubc.ca>> wrote:
Jeff,

of course I agree, Events and Actions may help describing what happens to archival objects. However, I think you highlighted a relevant point here. According to the initial request from Richard, we have been asked to identify the relevant properties needed to describe archival objects. I started identifying some "areas", i.e, aspects that we consider relevant, because I took Richard's request as a sort of identification of users' needs rather than properties. In fact, you "translated" the need for information on the history of objects in a set of classes and properties. In other words, once a need is identified and accepted, we'll find a way to represent it--and there may be indeed different solutions.

I think at this point is important to identify our needs, i.e. what we need to know about the objects. Once we agree on these needs, we may focus on the best way to represent them--either a new property, or a new class? either a specialization of a property or a new property? and so on.

Anyway, the short reply is, I agree with you.

Giovanni





On 2015-08-07 6:04 PM, Young,Jeff (OR) wrote:
1) yes, "owns" does half of the job, rather, part of it. Let me add something
more, just to share knowledge and clarify the archival perspective. Archives are
supposed to be repositories of authentic records. In order to guarantee and
maintain authenticity we need to know what happens to objects from creation
time till they come into our hands--any information gap may result in an
"authenticity gap", since we may not be able to guarantee that records have
not been tampered with, corrupted, misplaced etc. "What happens to objects"
means that we need to know of any change of either the real obejcts (i.e.,
change of format, amendments, compression...) or their context, that is, their
surroundings, including owners, custodians or any other agent who had a role
in maintaining the environment in which records are preserved.

It seems like http://schema.org/Event and/or http://schema.org/Action could help track the history of an item. The connection back to the ArchivalItem items could presumably be made using http://schema.org/object.

2) I'm not sure "hold" can be defined as a temporary ownership. For what I
know the difference is legal. Objects may be held for decades by agent X, yet
the property right may be held by agent Y. "To Hold" is about keeping stuff, "To
Own" is about having a title of property on it.

This seems somewhat analogous to https://schema.org/TradeAction cases where temporal/transient control can be expressed and attached to a thing, again via http://schema.org/object.


Jeff
3) Hence, the idea of enhancing OwnershipInfo doesn't seem to work to me,
because it is anyway a value of property "own", which is a different thing from
"hold/keep/whatever".

In short, I would go for a different property. I understand your concerns, so
maybe "Keep" may work. Otherwise, if we agree anyway that a class is needed,
let's call it "Foo1" for the moment---we'll find the label later.


re CreativeWorks:
I agree with you, except that while it is true that "archivists identify that they
have a need to describe a category [...] named Documents", it is not corrrect to
state that archivists identify such a category as a CreativeWork--we are just
discussing about it and see what the best solution is.

Giovanni



On 2015-08-07 3:20 PM, Richard Wallis wrote:
More good points and analysis - comments below...

~Richard

     1) with regard to the two potential approaches there is a major
     issue: "owns" (ie "Products owned by the organization or person"
     [sic]) is not an adequate property for describing custody. When we
     talk about custodial history we are not necessarily talking about
     owning. Archives may be deposited, or borrowed (e.g., for an
     exhibition), so at a given time they may be possessed by an archival
     institution, while being owned (i.e. possessed by right) by some
     other subject. The custodial history is the story of the custody,
     not the story of the owners. We need to trace it, because it
     provides fundamental information to assess authenticity.


Sounds like "owns" [with suitable expansion to include Things that are
not only Products] only does half the job, and we need a parallel
mechanism to describing temporary ownership or 'holding'.  One
possibility could be to enhance OwnershipInfo
<http://schema.org/OwnershipInfo> to be capable of describing
ownership of a temporary nature. Alternatively we could go for another
property to alongside owns. The name of 'holds' immediately comes to
mind but I fear it would not be acceptable to the the wider Schema.org
group due to alternative meanings in areas such as sport and medicine.


     2) with regard to archives as CreativeWorks, I agree with you: it
     cannot be argued that "a government document is not a type of
     CreativeWork", not because it is indeed, but because as a matter of
     fact CreativeWorks are not defined. It is strange though that we can
     find email messages, datasets, books, and any sort of things in the
     CreativeWorks bucket, while documents and records have not been
     mentioned at all. I think first of all we should define a class for
     Document, since the bulk of an archives is made by documents after all.


With the evolving nature of Schema.org it is not that surprising that
apparently obvious things are not yet represented in the vocabulary.
Types get into the vocabulary when a need is identified.  This is
exactly the process that we are engaged in here -- archivists identify
that they have a need to describe a category of CreativeWorks named
Documents and propose the creation of such a Type in an archives
extension or even potentially in the core vocabulary.

I have updated the Wiki Page
<https://www.w3.org/community/architypes/wiki/Main_Page> to reflect
this suggestion.


     Giovanni




     On 2015-08-07 1:04 AM, Richard Wallis wrote:

         Some good points Sarah - comments below...

              Two properties stick out to me that are not covered as far
         as I can
              tell in the generic Collection schema:

              1. Holding archives/institution: because archives are
         unique, it's
              important to record the institution that holds the collection.


              Related to this point:

              2. Custodial history, or the archival history of the collection
              before and during its custody in an institution. This is
         important
              to record for making presumptions of authenticity and
         understanding
              the limits to what the collection contains (e.g., half of
         it was
              lost in a fire, etc)


         There are a couple of potential approaches to these points.  Firstly
         coming at it from the holding organization's point of view:

            * Organization <http://schema.org/Organization> has an owns
              <http://schema.org/owns> property that has OwnershipInfo
              <http://schema.org/OwnershipInfo>  as one of the options in its
              range. OwnershipInfo <http://schema.org/OwnershipInfo> has some
              useful properties for capturing some of the things you describe
              associated with ArchivesCollections it may hold.
            * Some of the current descriptions of these properties are very
              Product focused, but recommending that an Organization can
              additionally own CreativeWorks (such as an
         ArchivesCollection) could
              well work.

         Secondly from the point of view of describing the same current and
         historical information for a collection:

            * The OwnershipInfo Type could be enhanced to include the owner
              Organization
            * The proposed ArchivesCollection could have an ownedBy
         property which
              would have Organization, Person, and OwnershipInfo in its
range


              Giovanni touched on this in the other thread covering items in
              collections.

              Re: CreativeWork: in addition to the examples that you raise
              Richard, there is a lot of content in archival collections
         which
              many would argue isn't "creative" in nature, such as data,
              governmental documents, etc. I would be glad to see us
         expand the
              hasPart idea beyond the scope of CreativeWork.


         So will I.  Not sure that in the generic Schema.org world that
         you could
         argue that a government document is not a type of CreativeWork, but
         there are many other non-CreativeWork items that can be found in
         Archives.





Received on Friday, 7 August 2015 19:29:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 August 2018 13:28:59 UTC