- From: Richard Wallis <richard.wallis@dataliberate.com>
- Date: Sun, 9 Aug 2015 20:43:00 +0100
- To: Giovanni Michetti <michetti@mail.ubc.ca>
- Cc: "Young,Jeff (OR)" <jyoung@oclc.org>, Sarah Romkey <sromkey@artefactual.com>, public-architypes <public-architypes@w3.org>
- Message-ID: <CAD47Kz4SXhqBfitwBHQ-RsMVRDEATPNbOE-o63i+tTHbXunybg@mail.gmail.com>
Giovanni, Yes you have, in areas to consider terms, you have covered things well. I think now we should start to drill down towards potential properties and some examples thereof. Your emphasis of the possible technical facets of access & use, raises a question that I believe will occur several times as we move forward. When is a descriptive need a consequence of an item being part of an archival collection, and when is just part of that item whatever the context? If the item is an 8 inch floppy disc, the need for a certain types of drive and software should be descriptive requirements anyway. In an archives context however a relationship to such resources, in the current or other archives, should be describable. Enjoy your vacation! ~Richard. On 9 August 2015 at 02:13, Giovanni Michetti <michetti@mail.ubc.ca> wrote: > Richard, > > I gave a further look at some other standards, including ISAD, RAD, DACS, > EAD, CIDOC CRM, and I don't have anyting to add to the list of > relevant aspects I've already laid out (i.e., identification, physical > characteristics etc.), except that I would like to make clear that access & > use may refer to technical access, ie technical requirements such as the > need for specific hardware or software. > > On a separate note, I'm going on vacation, so probably I won't be able to > join the discussion in the next two weeks--my apologies. > > Giovanni > > > > On 2015-08-07 8:27 PM, Richard Wallis wrote: > >> 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 Sunday, 9 August 2015 19:43:30 UTC