- From: Giovanni Michetti <michetti@mail.ubc.ca>
- Date: Sun, 9 Aug 2015 03:13:59 +0200
- To: Richard Wallis <richard.wallis@dataliberate.com>
- CC: "Young,Jeff (OR)" <jyoung@oclc.org>, Sarah Romkey <sromkey@artefactual.com>, public-architypes <public-architypes@w3.org>
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 01:15:05 UTC