Martin, Franco's rule may be restated as follows, still avoiding too many negations:
(R) A class MAY BE declared if, and only if, either or both of the following applies: (R1) it is required as the domain or range of a property inappropriate to its superclass, or (R2) it is a key concept in the practical scope In my original formulation it seemed that creating a class was compulsory if those conditions were verified, what of course is not the case: as you say, there may be other reasons not to start the process of new class creation. Further rule refinements/amendments welcome, together with a sister rule for properties, where the trick of Typization (i.e. using the superclass with P2 has type) has the limits we all know, i.e. generates a “dot” property (P999.1) that requires reification for proper RDF treatment. Like! to most of your comments about Remain/Leave; still unsure about E48. Ashes on my head (Repent!!) for confusing E49 Time Appellation and Period names, probably misled by same confusion in the head of some archaeologists who use these names to “date” something. So for them “Early bronze age” means the time span "3300 to 2700 BC”. In their mind, it is also an E4 Period and a “culture”, whatever the latter may mean. Confusion, as wisely Gardin pointed out: but they are not guilty, CRM-wise, because according to the present E49 scope note it can be "all forms of names or codes, such as historical periods, and dates, which are characteristically used to refer to a specific E52 Time-Span”. Best Franco Prof. Franco Niccolucci Director, VAST-LAB PIN - U. of Florence Scientific Coordinator ARIADNE - PARTHENOS Piazza Ciardi 25 59100 Prato, Italy > Il giorno 06 ago 2016, alle ore 17:21, martin <[email protected]> ha > scritto: > > Dear Franco, > > I widely agree with your judgement. Here my proposal: > > On 4/8/2016 4:28 πμ, Franco Niccolucci wrote: >> Hi all CRMers. >> >> >> >> Quoting from FORTH’s presentation at CAA2016 "Methodological tips for >> mappings to CIDOC CRM” by Bruseker, Dakalaki, Doerr & Theodoridou: >> >> "A class is not declared unless it is required as the domain or range of a >> property not appropriate to its superclass, or it is a key concept in the >> practical scope" >> >> Too many negations. I would restate it as follows (not + not = yes): >> >> (R) A class is declared if, and only if, either or both of the following >> applies: >> (R1) it is required as the domain or range of a property inappropriate to >> its superclass, or >> (R2) it is a key concept in the practical scope >> >> Do we agree on that? I do. >> > I agree with the rules, but only with the "only if", a class may not be > declared for other reasons as well, > we actually have more reasons not to declare a class. >> In light of the above rule, let’s check the subclasses of E41. Below I state >> “Remain” if (R) applies, “Leave” if it does not and we can get rid of the >> subclass with no damage. It sounds sort of Brexit, let’s call it CRMxit ;-) >> >> E42 Identifier - Remain. Reason: (R2), identifiers are an essential part of >> the game, otherwise what’s a PID? Uniqueness is also an (R1) reason. >> > I vote the same, actually also (R1) holds, because Identifiers do have > incoming properties P37, P38, and in FRBRoo R8. >> E44 Place Appellation - Remain. Reason: mainly (R2) but also (R1). Killing >> it would kill also E48. Don’t destruct gazetteers. If you want to know more, >> see my forthcoming paper on the Pleiades mapping, draft available on request >> - but after I return from summer holidays. BTW I like quoting (and >> advertising) myself since usually nobody else does. > I vote the same. >> E45 Address - Neutral, but preferably Leave. Due to the many aspects an >> address may take, no uniqueness, semantic irrelevance. Qualification with >> E55 Type “Address” is enough. Who cares about addresses? Only the mailman. >> Not decidedly for Leave because Address is an everyday concept, somehow >> superseded by the possibility of receiving everywhere (nowhere) >> communications by email, SMS, whatsapp and the like. On the other hand, >> Address as a special case of place appellation is confusing. > Addresses are particular constructs. As identifiers of a built area, and as > PO box for material mail they are by construct unambiguous compared to other > identifiers. No other identifiers will look like. > As Contact Point seems they seem to identifiers of services, electronic or > physical, which know how to resolve to the physical (machine or people) > behind. > Don't forget the URL resolution of an internet service provider. I vote for > REMAIN, and study the meaning of "service". >> E46 Section Definition - Uncertain, more towards Remain. Requires additional >> thought as in CRMarcheo and CRMba. If I remember well, used also in CRMsci. > I vote for LEAVE. It had always been confused with types of parts. Not used > in CRMsci, if I am not wrong. To be checked. >> E47 Spatial Coordinates - Remain. (R2), too important for CRMgeo to let it >> go. Also (R1) as they can be fed into further processing after they are >> identified by Type: long-lat, google maps, > I agree. >> chess coordinates "Queen in a1 - checkmate"; (but what about “Bishop’s pawn >> ahead by two", the second move of a Queen’s gambit; it’s a diversion, forget >> it) > Sure. mathematical spaces are not physical spaces. E47 applies only to earth. > Principle of "bottom up" development. When we understand virtual spaces > better, we may generalize. See also METS <area> concept > for addressing parts of information objects. >> E48 Place Name - Remain, of course, see above comment about E44. Place names >> are the quintessence of spatial reasoning about old texts that did not use >> coordinates but just names, so (R1) + (R2). > Here I am not sure, because the "Place Name" is normally a Physical Feature > name. All the ambiguity of name versus type of named item comes up again, and > the temporal indeterminacy of the feature in contrast to place. I'd rather > vote for LEAVE. I do not see an (R1)? >> >> Not relevant if places are named after people living there, as in ancient >> Norway and probably in ancient everywhere. Here in Italy there are many >> place names like “Case Passerini” near Florence, the current location of a >> waste treatment plant (the right location for future, 30th century >> archaeological investigations), which is clearly named after a Passerini >> family nobody knows about. Also, typical English use: “Let’s see at Martin’s >> for dinner” with the genitive (possessive) used as locative like in some >> cases in Latin. >> > Exactly, the locative case disambiguates the type of the referred. So, we can > introduce a E53 Place P1 is identified by Appellation, without causing any > ambiguity, isn't it? >> E49 Time Appellation - Remain!!! Both for (R1) and (R2). > I agree, for time expressions and rulership names used globally as time. >> How could archaeologists dispense with named periods? There are plenty of >> papers (including some of mine) dealing with time period name resolution. >> Killing E49 would destroy archaeological documentation, how could >> archaeologists writing papers without mentioning “Upper Eneolithic” or >> “Early Classic Cypriot IV". > But the latter are names of E4 Period, and not Time Appellations. Just an E4 > Period is identified by.... >> E50 Date - Perhaps Remain but not strictly necessary, personally I would be >> for Leave. In my opinion it is a pseudo-concept. i would prefer to >> distinguish between time-stamp if precise to some granularity level >> (year/day/hour and minutes as in ISO8601), and a Time Appellation with type >> date if not. Is “Martin Doerr’s birth day” a date? according to the E50 >> scope note, it seems to be, in the CRM world at least. But practical, >> everyday use may suggest Remain. >> > I suggest LEAVE. The distinction to Time Appellation is not sufficient I'd > argue. >> E75 Conceptual Object Appellation - Uncertain, Revise. The scope note is >> unpleasant, it looks more an identifier than an appellation. "Pythagora’s >> theorem” is the name (= appellation) of the theorem everybody knows, but it >> is uncertain if it is an E75, probably not. > I propose a LEAVE. Exactly because what we are interested in, ISBN numbers > etc., are Identifiers. >> E82 Actor Appellation - Leave. Scope note unpleasant: "any sort of name, >> number, code or symbol characteristically used to identify an E39 Actor”. >> How do I know it is an E39 Actor, itself an imprecise (Bernini’s Fountain in >> Piazza di Spagna heavily damaged in 2015 by hooligan Feyenoord supporters, >> are these an E39? or only the temporary grouping of the unidentified ones >> who actually did it?) but unfortunately necessary concept? >> “Characteristically”? Come on... >> Bye bye E82. >> > I vote the same. >> >> >> E51 Contact Point - Leave. Irrelevant, bureaucratic, pernickety, >> unnecessary, indeterminate. Is this an official job, like “What is your job >> at FORTH? I am an E51 contact point! Ah, great, you must earn a good salary >> for that”. Also Amazon believes I am >> [email protected] for my family's purchases, and I started >> thinking the same (my cat does as well, she’s going to send emails when >> hungry). Resolved with Type, same as with other more important >> qualifications as director, curator etc or email, skype-nickname, etc. > I vote REMAIN, until we have understood the nature of communication services. >> E35 Title - Remain. Of course. An E41 Appellation (Leonardo’s Masterpiece) >> is not a Title (Mona Lisa), it is just an Appellation. However, there are >> two titles for this painting, one used in English (Mona Lisa) and one in >> Italian and French (La Gioconda, La Joconde), not translations of each >> other. This is not forbidden by the scope note, but perhaps stating that >> title uniqueness (beyond straight literal translation) is not implied, would >> clarify. This applies to other works as well, typically to movies sometimes >> weirdly re-titled by distributors in different countries. Since the scope >> note mentions that also the translation of a Title is a Title, adding that >> also the non-translation of a Title may be a Title would not hurt. Otherwise >> some people could think that “Mona Lisa” is “THE" title, while it is only >> “A" title. Don’t call it the English Title, classes cannot have >> qualificative adjuctoves. >> By the way what is a “work”, the term used in the scope note of E35? Why not >> calling it an E71 Man-made Thing, as it is? One has to go through the scope >> note of P102 has title, to discover it. If “work" is defined elsewhere, call >> it properly by name, not generically. >> This would re-open an old issue: is the Title, >> (a) the Title of the material object (E24), identified by Louvre inventory >> no. 779 hanging on the wall in room 6 of first floor at Louvre named >> (titled?) La Salle de La Joconde; or >> (b) the Title of the immaterial object (E28), of which the above-mentioned >> painting Louvre id 779 and on display at the Louvre, is the (one?) >> materialization; or >> (c) both (a) and (b). >> > Interesting question. The scope note says: "Titles may be assigned by the > creator of the work itself, or by a social group. " > > Appellations in general are not unique. There are enough Martin in the world, > including bird species, plane models, first names, last names. Why restrict? >> Easy (?) question for an ancient, unique painting, less easy for multiples - >> maybe before answering you may wish to read Walter Benjamin’s “The work of >> art in the Age of Mechanical Reproducibility”. Without much thinking on it, >> I would go (gut-feelingly) for (b). But I am going off-topic, let’s keep >> this discussion for another time. Possible external references, e.g. to >> FRBR, should however be mentioned in the scope note. >> >> Enough for you, the survivors of a SIG meeting; thanks to those who had the >> patience of reading up to here. For all, time for holidays now. >> > Thank you for your arguments! > > martin >> All the best >> >> Franco >> >> >> Prof. Franco Niccolucci >> Director, VAST-LAB >> PIN - U. of Florence >> Scientific Coordinator >> ARIADNE - PARTHENOS >> >> Piazza Ciardi 25 >> 59100 Prato, Italy >> >> >> >> >>> Il giorno 03 ago 2016, alle ore 07:42, Christian-Emil Smith Ore >>> <[email protected]> >>> ha scritto: >>> >>> >>> >>> The sub classes of appellation, e.g. actor appellation and place >>> appelletion were introduced in crm around 2001-2002. At that time there was >>> a view that there were special characteristica for place name and actor >>> names which made it possible to detect and differenciate between them. >>> This has been proven to be a not correct assumption. >>> In pre industrial societies, at least in Norway, the name and the "address" >>> were mixed. >>> >>> The subclasse tree of E41 is >>> >>> E41 Appellation >>> E42 - >>> Identifier >>> E44 - >>> Place Appellation >>> E45 - >>> - Address >>> E46 - >>> - Section Definition >>> E47 - >>> - Spatial Coordinates >>> E48 - >>> - Place Name >>> E49 - >>> Time Appellation >>> E50 - >>> - Date >>> E75 - >>> Conceptual Object Appellation >>> E82 - >>> Actor Appellation >>> E51 - >>> Contact Point >>> E45 - >>> - Address >>> E35 - >>> Title >>> >>> Do we really want to delete all but E35 Title, E45 Address and E47 Spatial >>> Coordinates? >>> >>> Best >>> Christian-Emil >>> >>> From: Crm-sig >>> <[email protected]> on behalf of martin <[email protected]> >>> >>> Sent: 02 August 2016 19:28 >>> To: >>> [email protected] >>> >>> Subject: Re: [Crm-sig] E82 Actor Appellation Issue >>> >>> I also vote for complete removal, together with all others except for >>> Title, address and coordinates >>> >>> On 2/8/2016 11:30 πμ, Stephen Stead wrote: >>> >>>> The scope note and examples of E82 Actor Appellation do not clearly convey >>>> the idea that the appellation must be of a form that is characteristically >>>> an appellation of an actor. This is causing confusion in the user >>>> community. >>>> One alternative is to retire E82 altogether and the other is to update the >>>> scope note. >>>> I would vote for deprecation/retirement. >>>> >>>> I have also suggested a new scope note and changed examples:- >>>> E82 Actor Appellation >>>> Subclass of: E41 Appellation >>>> >>>> Scope note: This class comprises any sort of name, number, code or >>>> symbol characteristically used to identify an E39 Actor. >>>> >>>> An E39 Actor will typically have more than one E82 Actor Appellation, and >>>> instances of E82 Actor Appellation in turn may have alternative >>>> representations. The distinction between corporate and personal names, >>>> which is particularly important in library applications, should be made by >>>> explicitly linking the E82 Actor Appellation to an instance of either E21 >>>> Person or E74 Group/E40 Legal Body. If this is not possible, the >>>> distinction can be made through the use of the P2 has typemechanism. >>>> Examples: >>>> § “John Doe” >>>> § “Doe, J” >>>> § “the U.S. Social Security Number 246-14-2304” >>>> § “the Artist Formerly Known as Prince” >>>> § “the Master of the Flemish Madonna” >>>> § “Raphael’s Workshop” >>>> § “the Brontë Sisters” >>>> § “ICOM” >>>> § “International Council of Museums” >>>> >>>> E82 Actor Appellation >>>> Subclass of: E41 Appellation >>>> >>>> Scope note: This class comprises any sort of name, number, code or >>>> symbol characteristically used to identify an E39 Actor. That is the very >>>> form of the name indicates that it is an appellation of an instance of E39 >>>> Actor. >>>> >>>> An E39 Actor will typically have more than one E82 Actor Appellation, and >>>> instances of E82 Actor Appellation in turn may have alternative >>>> representations. The distinction between corporate and personal names, >>>> which is particularly important in library applications, should be made by >>>> explicitly linking the E82 Actor Appellation to an instance of either E21 >>>> Person or E74 Group/E40 Legal Body. If this is not possible, the >>>> distinction can be made through the use of the P2 has typemechanism. >>>> Examples: >>>> § the U.S. Social Security Number “246-14-2304” >>>> § UK Company Number “2374216” >>>> § Leonardo da Vinci’s ULAN identifier “ULAN500010879” >>>> >>>> Rgds >>>> SdS >>>> >>>> Stephen Stead >>>> Director >>>> Paveprime Ltd >>>> 35 Downs Court Rd >>>> Purley, Surrey >>>> UK, CR8 1BF >>>> Tel +44 20 8668 3075 >>>> Fax +44 20 8763 1739 >>>> Mob +44 7802 755 013 >>>> E-mail >>>> [email protected] >>>> >>>> LinkedIn Profile >>>> http://uk.linkedin.com/in/steads >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Crm-sig mailing list >>>> >>>> >>>> [email protected] >>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >>> -- >>> >>> -------------------------------------------------------------- >>> Dr. Martin Doerr | Vox:+30(2810)391625 | >>> Research Director | Fax:+30(2810)391638 | >>> | Email: >>> >>> [email protected] >>> >>> | >>> | >>> Center for Cultural Informatics | >>> Information Systems Laboratory | >>> Institute of Computer Science | >>> Foundation for Research and Technology - Hellas (FORTH) | >>> | >>> N.Plastira 100, Vassilika Vouton, | >>> GR70013 Heraklion,Crete,Greece | >>> | >>> Web-site: >>> >>> http://www.ics.forth.gr/isl >>> >>> | >>> -------------------------------------------------------------- >>> >>> >>> _______________________________________________ >>> Crm-sig mailing list >>> >>> [email protected] >>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> _______________________________________________ >> Crm-sig mailing list >> >> [email protected] >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > > > -- > > -------------------------------------------------------------- > Dr. Martin Doerr | Vox:+30(2810)391625 | > Research Director | Fax:+30(2810)391638 | > | Email: > [email protected] > | > | > Center for Cultural Informatics | > Information Systems Laboratory | > Institute of Computer Science | > Foundation for Research and Technology - Hellas (FORTH) | > | > N.Plastira 100, Vassilika Vouton, | > GR70013 Heraklion,Crete,Greece | > | > Web-site: > http://www.ics.forth.gr/isl > | > -------------------------------------------------------------- > > > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig
