From tsoulouha at ics.forth.gr Fri Apr 1 17:48:17 2022 From: tsoulouha at ics.forth.gr (Eleni Tsoulouha) Date: Fri, 1 Apr 2022 17:48:17 +0300 Subject: [Crm-sig] Next *IN PERSON* CIDOC CRM/FRBRoo Sig Meeting Message-ID: <015f3780-d2fe-dbdb-2579-21abc0c01e87@ics.forth.gr> ** *Dear all,* * The 53rd CIDOC CRM & 46th FRBRoo Sig meeting will take place on 10-13 May 2022 atFORTH (Crete). It will be a physical meeting, but the option of an online participation will be available for those not able to attend in person (details will be shared through the list in due course). You are kindly asked to indicate if you are planning to attend, by filling in the registration form? (link here ). The agenda will be announced in about two weeks from now. All the sessions will be held in the Room "Stelios Orphanoudakis" (Central building, 1rst floor). You can find a plan of the campus at FORTH below: Additional information on how to reach the premises can be found here . Looking forward to meeting you all in person :) Eleni * -------------- next part -------------- An HTML attachment was scrubbed... URL: From pat.riva at concordia.ca Mon Apr 4 02:27:20 2022 From: pat.riva at concordia.ca (Pat Riva) Date: Sun, 3 Apr 2022 23:27:20 +0000 Subject: [Crm-sig] E-vote: LRMoo F28 Expression Creation In-Reply-To: References: Message-ID: Thank you all. For this vote I count 6 Yes and none opposed. I will integrate these modification. Pat Pat Riva Acting University Librarian / Biblioth?caire en chef par int?rim Concordia University / Universit? Concordia 1455 de Maisonneuve West, LB-331 Montr?al, Qu?bec H3G 1M8 Canada pat.riva at concordia.ca ________________________________ From: Crm-sig on behalf of Pat Riva via Crm-sig Sent: March 27, 2022 11:22 PM To: CRM-SIG Subject: [Crm-sig] E-vote: LRMoo F28 Expression Creation Hello all, Continuing the series of e-votes to complete outstanding homework. Following the discussion of F28 during SIG 52 in February, further editing of the final two paragraphs of the proposed scope note of F28 Expression Creation remained. On further analysis, the path information presented in the last paragraph of the F28 scope note seems better placed under R2 is derivation of (for works) and F27 Work Creation (as recently e-voted). This vote is for the related changes to F28, R2 and F27. Please vote Yes to accept the revised scope notes, or No to not accept them. If voting no, please explain. I will summarize votes to the list on April 3. a) Full scope note of F28 Expression Creation (first 3 paragraphs accepted in February and given for context) 4th paragraph: revised text proposed, to be voted, points to usage of the new R76 property 5th paragraph: move first sentence to F27, path explanation to R2, see parts b) and c) Scope note: This class comprises activities that result in instances of F2 Expression coming into existence. An instance of F2 Expression is considered to be created when it is captured on a carrier other than the creator?s brain. Although F2 Expression is an abstract entity, a conceptual object, the creation of an expression inevitably also affects the physical world: when you scribble the first draft of a poem on a sheet of paper, you produce an instance of F3 Manifestation and an instance of F5 Item. F28 Expression Creation is a subclass of E12 Production because the recording of the expression causes a physical modification of the E18 Physical Thing that serves as the carrier. The creation of an instance of F2 Expression coincides with the creation of the first instance of F3 Manifestation that R4 embodies (is embodied in) this instance of F2 Expression. The P2 has type (is type of) property can be used to specify the type of the instance of F28 Expression Creation (i.e., activities such as translating, revising, or arranging music are types of creation process). The type of the process is distinct from the type of result even though the typology frequently used for instances of the resulting F2 Expressions may imply the category of the instance of the F28 Expression Creation. An instance of F28 Expression Creation may use as source material one or more specific instances of F2 Expression. When the source expression is documented this is also expressed by the property R76 is derivative of (has derivative). In the situation where an expression of one instance of F1 Work serves as source material for the creation of the first expression of a new instance of F1 Work, the relationship between the works is indicated using the property R2 is derivative of (has derivative) between the two instances of F1 Work. Path: F1 Work(1). R3 is realised in: F2 Expression(1). P16i was used for: F28 Expression Creation. R17 created: F2 Expression(2). R3i realises: F1 Work(2). R2 is derivative of: F1 Work(1). b) Addition to the scope note of R2 is derivative of (has derivative) -Add 2nd paragraph explaining the path showing the derivation of one work from another. -Add mention at the end of the first paragraph that the property is asymmetric and irreflexive (following the pattern established with issue 517) Scope note: This property associates an instance of F1 Work which modifies the content of another instance of F1 Work with the latter. This property is transitive, asymmetric and irreflexive. The inverse of this property is equivalent to the developed path: F1 Work(1). R3 is realised in: F2 Expression(1). P16i was used for: F28 Expression Creation. R17 created: F2 Expression(2). R3i realises: F1 Work(2). That is, F1 Work(1). R2i has derivative: F1 Work (2), without needing to specify the specific expressions involved in the derivation. The property R2.1 has type of this property allows for specifying the kind of derivation, such as adaptation, summarisation, etc. c) Addition to the scope note of F27 Work Creation, last paragraph -The addition points to the use of R2 to document work creation based on another work. (the starting point is the scope note as modified by the preceding e-vote ending March 20, 2022) Scope note: This class comprises activities by which instances of F1 Work come into existence. An instance of F27 Work Creation can serve to document the period a work was coming into existence and the circumstances of it, when these are known. An instance of F27 Work Creation marks the initial creation of an instance of F1 Work through expressions or other externalisations that are sufficiently elaborated so that the characteristic conceptual identity of the work could be recognized as existing. In many cases this will coincide with the first known complete externalisation of an expression of the work. In other cases, the initial creation of an instance of F1 Work may be inferred from multiple, or later, expressions or other forms of evidence. For instance, commissioning of a work may explicitly be agreed on after the presentation of an already complete and detailed elaboration of the work that was not made public. Performances may be prior to written expressions, as in the case of Shakespeare?s works. The work, as an intellectual construction, may evolve from its initial creation onwards, until the last known expression of it. An instance of E39 Actor with which a work is associated through the chain of properties F1 Work. R16i was created by: F27 Work Creation. P14 carried out by: E39 Actor corresponds to the notion of the ?creator? of the work. In the situation where an expression of one instance of F1 Work serves as source material for the creation of the first expression of a new instance of F1 Work, the relationship between the works is indicated using the property R2 is derivative of (has derivative) between the two instances of F1 Work. Pat Riva Acting University Librarian / Biblioth?caire en chef par int?rim Concordia University / Universit? Concordia 1455 de Maisonneuve West, LB-331 Montr?al, Qu?bec H3G 1M8 Canada pat.riva at concordia.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: From pat.riva at concordia.ca Mon Apr 4 02:28:48 2022 From: pat.riva at concordia.ca (Pat Riva) Date: Sun, 3 Apr 2022 23:28:48 +0000 Subject: [Crm-sig] Call for e-vote: LRMoo R26 In-Reply-To: References: Message-ID: Thank you all for this vote also. I count 7 Yes, and none opposed. I will integrate the modifications. Pat Pat Riva Acting University Librarian / Biblioth?caire en chef par int?rim Concordia University / Universit? Concordia 1455 de Maisonneuve West, LB-331 Montr?al, Qu?bec H3G 1M8 Canada pat.riva at concordia.ca ________________________________ From: Crm-sig on behalf of Pat Riva via Crm-sig Sent: March 20, 2022 4:32 PM To: CRM-SIG Subject: [Crm-sig] Call for e-vote: LRMoo R26 Hello all, Continuing with issues partially discussed but not actually voted at SIG#52 in February. In the document for Issue 360: HW: F28 Expression Creation, we did not complete the fourth part, relating to deprecating LRMoo property R26 produced things of type (was produced by). R26 links the F32 Carrier Production Event directly to E99 Product Type. This is superfluous because property R27 materialized (was materialized by) links F32 Carrier Production Event to F3 Manifestation, and the F3 that is produced via F32 is necessarily multiply instantiated as E99. There is no need to link F32 directly to E99. Therefore, the proposal is to deprecate R26. For consistency, delete the last sentence of F32 scope note (highlighted in italics) which refers to R26. *Please vote Yes to accept the proposal to deprecate R26 (and to remove the sentence referring to it from the F32 scope note), or No to reject the proposal. If voting No, please explain. I will summarize the results to the list on April 3. For reference, the relevant scope notes follow. R26 produced things of type (was produced by) Domain: F32 Carrier Production Event Range: E99 Product Type Subproperty of: E12 Production. P186 produced thing of product type (is produced by): E99 Product Type Quantification: (1,n:0,n) Scope note: This property associates an instance of F32 Carrier Production Event directly with the instance of E99 Product Type that is the prototype displaying the features that all of the F5 Items produced should display. This property is used in preference to R27 materialized (was materialized by) when the instance of F3 Manifestation that is materialized by the instance of F32 Carrier Production Event is also an instance of E99 Product Type. R27 materialized (was materialized by) Domain: F32 Carrier Production Event Range: F3 Manifestation Subproperty of: E7 Activity. P16 used specific object (was used for): E70 Thing Quantification: (0,n:0,n) Scope note: This property associates an instance of F32 Carrier Production Event with the set of signs provided by the publisher to be carried by all of the produced items (i.e., the instances of F5 Item) and any other physical features foreseen as integral to the instance of F3 Manifestation that is materialised. F32 Carrier Production Event Subclass of: E12 Production Scope note: This class comprises activities that result in instances of F5 Item coming into existence. Both the production of a series of physical objects (printed books, scores, CDs, DVDs, CD-ROMs, etc.) and the creation of a new copy of a file on an electronic carrier are regarded as instances of F32 Carrier Production Event. Typically, the production of copies of a publication (no matter whether it is a book, a sound recording, a DVD, a cartographic resource, etc.) strives to produce items all as similar as possible to a prototype that displays all the features that all the copies of the publication should also display, which is reflected in the property R27 materialized: F3 Manifestation. In the case where the instance of F3 Manifestation that is materialized is also an instance of E99 Product Type, the property R26 produced things of type is the preferred method to associate the instance of F32 Carrier Production Event directly with the instance of E99 Product Type. Thanks, Pat Pat Riva Acting University Librarian / Biblioth?caire en chef par int?rim Concordia University / Universit? Concordia 1455 de Maisonneuve West, LB-331 Montr?al, Qu?bec H3G 1M8 Canada pat.riva at concordia.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: From pat.riva at concordia.ca Mon Apr 4 06:08:48 2022 From: pat.riva at concordia.ca (Pat Riva) Date: Mon, 4 Apr 2022 03:08:48 +0000 Subject: [Crm-sig] E-vote: LRMoo, deprecation of R10 has member Message-ID: Hello all yet again! Property R10 has member (is member of) was discussed in October 2021, during SIG51. And had been discussed a few times prior to that. However, no vote was taken at SIG51 and the decision was deferred. We ran out of time to return to the discussion during SIG52 in February. It is time to take a vote and move on. The proposal is to deprecated R10 has member (is member of) which relates two instances of F1 Work. This property is from FRBRoo where it served to gather and link instances of F14 Individual Work into F15 Complex Works. All these subclasses of F1 Work have been deprecated in LRMoo, and furthermore, R10 does not not correspond to any relationship in LRMer. If the deprecation of R10 is accepted, then it is necessary to adjust R67 has part (forms part of), linking an instance of F1 Work to a larger instance of F1 Work, by removing the final paragraph and modifying its superproperty. Vote Yes if you support deprecating R10 (and adjusting R67 in consequence), vote No if you do not, preferably with an explanation. Indicate VETO if you consider this issue needs to be discussed at a SIG. Please vote by April 10 and I will summarize for the list. a) Current definition of R10 has member (is member of) Domain: F1 Work Range: F1 Work Superproperty of: F1 Work. R67 has part (is part of): F1 Work Subproperty of: E89 Propositional Object. P148 has component (is component of): E89 Propositional Object Quantification: many to many (0,n:0,n) Scope note: This property associates an instance of F1 Work with another instance of F1 Work that forms a part of it. This property is transitive. An instance of F1 Work may neither directly nor indirectly be a member of itself. Instances of F1 Work that are not members of one another may not share a common member. b) Current definition of R67 has part (forms part of) Domain: F1 Work Range: F1 Work Subproperty of: F1 Work. R10 has member (is member of): F1 Work Quantification: many to many (0,n:0,n) Scope note: This property associates an instance of F1 Work with another instance of F1 Work that forms part of it in a complementary role to other sibling parts, conceived at some point in time to form together a logical whole, such as the parts of a trilogy. This property is transitive. In contrast, the property R10 has member (is member of) may, for instance, also associate with the overall instance of F1 Work translations, adaptations and other derivative works that do not form a logical whole with sibling parts. Changes for R67 if R10 is deprecated : a) Modify superproperty to be the superproperty of the deprecated R10: Subproperty of: E89 Propositional Object. P148 has component (is component of): E89 Propositional Object b) Delete the 2nd paragraph of the scope note. In contrast, the property R10 has member (is member of) may, for instance, also associate with the overall instance of F1 Work translations, adaptations and other derivative works that do not form a logical whole with sibling parts. Pat Riva Acting University Librarian / Biblioth?caire en chef par int?rim Concordia University / Universit? Concordia 1455 de Maisonneuve West, LB-331 Montr?al, Qu?bec H3G 1M8 Canada pat.riva at concordia.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: From c.e.s.ore at iln.uio.no Mon Apr 4 09:22:39 2022 From: c.e.s.ore at iln.uio.no (Christian-Emil Smith Ore) Date: Mon, 4 Apr 2022 06:22:39 +0000 Subject: [Crm-sig] E-vote for scope note part of issue 294 (CRMarchaeo) In-Reply-To: References: Message-ID: Dear all, The result of this e-vote is 8 yes 0 no 0 veto Best, Christian-Emil ________________________________ From: Christian-Emil Smith Ore Sent: 21 March 2022 12:24 To: crm-sig Subject: E-vote for scope note part of issue 294 (CRMarchaeo) Dear all, As the issue number indicates issue 294 has been with for a while. In the 49th joint meeting of the CIDOC CRM SIG and SO/TC46/SC4/WG9; 42nd FRBR ? CIDOC CRM Harmonization meeting, the sig accepted MD's proposal to change the quantification of appears in, restricted to, typical for to many-to-many, as well as redraft their scope notes. The properties will be assigned the following AP numbers: * AP29 appears in * AP30 restricted to * AP31 typical for The new scope notes are working definitions. The relations among types (issue 407) be taken into account, together with skos and other standards. HW: SdS to edit them. The edited version of the scope notes can be found here (and copied in a the end of this email: https://drive.google.com/drive/folders/1qS8aBP3UVLGn-WAXH6aH2vZp4wy1ME3t You are invited to vote on the scope note texts (not the name of the inverses which will be a separate e-vote) YES if you accept the edited texts NO if you don't accept the edited texts VETO if you think a e-vote is not ok at the current state The voting is open until 4th April. Best, Christian-Emil 294: E55 Type relations The SdS edits. The original text is highlighted in Yellow to make it easier to follow the differences. OLD AP29 appears in Domain: E55 Type Range: E4 Period Subproperty: Quantification: many-to-many (0,n:0,n) Scope note: This property associates a kind of object (documented as an instance of E55) to an instance of E4 Period for indicating that objects of this kind have been generated within this period. The generation of such objects may be the result of human, biological, geological or other processes. This property makes a weak statement with regards to the distribution of the class of object in the archaeological record, but also in geological or paleontological observations: If the genesis of an object of this type can plausibly be assumed to fall within the genesis of the context in which it was found, then the statement made with this property would support reasoning, ceteris paribus, that the genesis period of the find context forms part of or overlaps with one of the instance of E4 Period in which the respective object type has appeared. Stronger claims can be made using ?typical for? and ?restricted to? properties. NEW AP29 appears in Domain: E55 Type Range: E4 Period Subproperty: Quantification: many-to-many (0,n:0,n) Scope note: This property associates a kind of object (documented as an instance of E55 Type) with an instance of E4 Period indicating that objects of this kind have been brought into existence during this period. The genesis of such objects may be the result of human, biological, geological or other processes. This property makes a weak statement about the distribution of the associated object kind in the archaeological record: that is, if the genesis of an object of the type can plausibly be assumed to fall within the genesis of the context within which it was found, then this property supports reasoning, ceteris paribus, that the genesis period of the context forms part of, or overlaps with, one of the instances of E4 Period in which the respective object type has appeared. Such weak statements may also be useful in the context of geological or paleontological observations. Stronger claims can be made using the properties AP30 restricted to and AP31 typical for. OLD AP30 restricted to Domain: E55 Type Range: E4 Period Subproperty: appears in Quantification: many-to-many (0,n:0,n) Scope note: This property associates a kind of object (documented as an instance of E55) to an instance of E4 Period for indicating that objects of this kind have exclusively been generated in this period. This property makes a strong statement concerning the distribution of the kind of object in the observation record: If the genesis of an object of this type can plausibly be assumed to fall within the genesis of the context in which it was found, then the statement made with this property would support reasoning, ceteris paribus, that the genesis period of the find context actually forms part of the related instance of E4 Period, or at least overlaps with it. In contrast, objects from previous periods may appear in a context because they are still in use, and objects from later periods may have been pushed into an older context. Weaker claims can be made using the properties ?typical for? and ?appears in?. In First Order Logic: [?] AP30(x,y) ? AP30(x,z) ? P132(y,z) NEW AP30 restricted to Domain: E55 Type Range: E4 Period Subproperty: AP29 appears in Quantification: many-to-many (0,n:0,n) Scope note: This property associates a kind of object (documented as an instance of E55 Type) with an instance of E4 Period indicating that objects of this kind have been generated exclusively in this period. This property makes a strong statement concerning the distribution of the associated object kind in the observed record: If the genesis of an object of this type can plausibly be assumed to fall within the genesis of the context in which it was found, then the statement made with this property would support reasoning, ceteris paribus, that the genesis period of the find context actually forms part of the related instance of E4 Period, or at least overlaps with it. In contrast, objects from previous periods may appear in a context because they are still in use, and objects from later periods may have been displaced into an older context. Weaker claims can be made using the properties AP29 appears in and AP31 typical for. In First Order Logic: [?] AP30(x,y) ? AP30(x,z) ? P132(y,z) OLD AP31 typical for Domain: E55 Type Range: E4 Period Subproperty: AP29 appears in Quantification: many-to-many (0,n:0,n) Scope note: This property associates a kind of object (documented as an instance of E55 Type) to an instance of E4 Period for indicating that objects of this kind have been generated in this period in significantly higher numbers and wider distribution, than in other periods. This property makes a moderate statement concerning the distribution of the kind of object in the observation record: If a sufficient number of objects of this type are found in some context, and their genesis can plausibly be assumed to fall within the genesis of the find context, then the statement made with this property would support reasoning, ceteris paribus, that the genesis period of the find context is likely to forms part of the related instance of E4 Period, or at least overlaps with it. ?Sufficient number? means that the density of objects of this kind in the find context is compatible with the general density this kind of object had in the respective period in comparable contexts and deposition history. A stronger claim can be made using ?restricted to? while a weaker claim is made using ?appears in'. NEW AP31 typical for Domain: E55 Type Range: E4 Period Subproperty: AP29 appears in Quantification: many-to-many (0,n:0,n) Scope note: This property associates a kind of object (documented as an instance of E55 Type) with an instance of E4 Period indicating that objects of this kind have been generated in this period in significantly greater numbers and in wider distributions, than in other periods. This property makes a moderate statement concerning the distribution of the associated object kind in the observed record: If a "sufficient number" of objects of this type are found in a context, and their genesis can plausibly be assumed to fall within the genesis of the find context, then the statement made with this property would support reasoning, ceteris paribus, that the genesis period of the find context is likely to form part of the related instance of E4 Period, or at least overlap with it. ?Sufficient number? means that the density of objects of this kind in the find context is compatible with the general density that this kind of object had during the associated period in contexts of a comparable nature and deposition history. A stronger claim can be made using AP30 restricted to while a weaker claim would use AP29 appears in. -------------- next part -------------- An HTML attachment was scrubbed... URL: From choffepierre at gmail.com Mon Apr 4 11:22:58 2022 From: choffepierre at gmail.com (=?UTF-8?q?Pierre_Choff=C3=A9?=) Date: Mon, 04 Apr 2022 08:22:58 +0000 Subject: [Crm-sig] E-vote: LRMoo, deprecation of R10 has member In-Reply-To: References: Message-ID: <624aaaa0b463285aac000001@polymail.io> I vote YES Pierre On Mon, Apr 4th, 2022 at 5:08 AM, Pat Riva via Crm-sig wrote: > > Hello all yet again! > > > > > Property?R10 ( > https://docs.google.com/document/d/1GgfF8Mi6EAduLyCBH9MZq4uSOX3C4sftnlKHUG-huWI/edit?usp=sharing > )?has member (is member of) was discussed in October 2021, during SIG51. > And had been discussed a few times prior to that. However, no vote was > taken at SIG51 and the decision was deferred. We ran out of time to return > to the discussion during SIG52 in February. It is time to take a vote and > move on. > > > > > > > > > The proposal is to deprecated R10 has member (is member of) which relates > two instances of F1 Work. This property is from FRBRoo where it served to > gather and link instances of F14 Individual Work into F15 Complex Works. > All these subclasses of F1 Work have been deprecated in LRMoo, and > furthermore, R10 does not not correspond to any relationship in LRMer. > > > > > > > > > If the deprecation of R10 is accepted, then it is necessary to adjust R67 > has part (forms part of), linking an instance of F1 Work to a larger > instance of F1 Work, by removing the final paragraph and modifying its > superproperty. > > > > > > > > > Vote *Yes* if you support deprecating R10 (and adjusting R67 in > consequence), vote *No* if you do not, preferably with an explanation. > Indicate *VETO* if you consider this issue needs to be discussed at a SIG. > > > > > > > > > > Please vote by *April 10* and I will summarize for the list. > > > > > > > > > a) Current definition of R10 has member (is member of) > > > > > > > > > Domain: F1 Work > > > > Range: F1 Work > > > > Superproperty of: F1 Work. R67 has part (is part of): F1 Work > > > > Subproperty of: E89 Propositional Object. P148 has component (is component > of): E89 Propositional Object > > > > Quantification: many to many (0,n:0,n) > > > > Scope note: This property associates an instance of F1 Work with another > instance of F1 Work that forms a part of it. This property is transitive. > An instance of F1 Work may neither directly nor indirectly be a member of > itself. Instances of F1 Work that are not members of one another may not > share a common member. > > > > > > > > > > b) Current definition of R67 has part (forms part of) > > > > Domain: F1 Work > > > > Range: F1 Work > > > > Subproperty of: F1 Work. R10 has member (is member of): F1 Work > > > > Quantification: many to many (0,n:0,n) > > > > Scope note: This property associates an instance of F1 Work with another > instance of F1 Work that forms part of it in a complementary role to other > sibling parts, conceived at some point in time to form together a logical > whole, such as the parts of a trilogy. This property is transitive. > > > > *In contrast, the property R10 has member (is member of) may, for > instance, also associate with the overall instance of F1 Work > translations, adaptations and other derivative works that do not form a > logical whole with sibling parts.* > > > > > > > > > Changes for R67 if R10 is deprecated : > > > > a) Modify superproperty to be the superproperty of the deprecated R10: > > > > Subproperty of: E89 Propositional Object. P148 has component (is component > of): E89 Propositional Object > > > > b) Delete the 2 nd paragraph of the scope note. > > > > > In contrast, the property R10 has member (is member of) may, for instance, > also associate with the overall instance of F1 Work translations, > adaptations and other derivative works that do not form a logical whole > with sibling parts. > > > > > > > > > > > Pat Riva > Acting University Librarian / Biblioth?caire en chef par int?rim > Concordia University / Universit? Concordia > 1455 de Maisonneuve West, LB-331 > Montr?al, Qu?bec H3G 1M8 > Canada > pat.riva at concordia.ca > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at ics.forth.gr Mon Apr 4 21:09:48 2022 From: martin at ics.forth.gr (Martin Doerr) Date: Mon, 4 Apr 2022 21:09:48 +0300 Subject: [Crm-sig] E-vote: LRMoo, deprecation of R10 has member In-Reply-To: References: Message-ID: Dear All, I vote VETO. Reason: The proposed scope note for R67 will still contain: "conceived at some point in time to form together a logical whole". This means to my opinion, that by deprecating R10, an instance of Work cannot evolve over time into some subsets that, following one group of librarians, form a Work in its own right, and following another group of librarians, form only expressions of the same work. This implies absolute, global decisions about instances of Work, rather breaking the ability to integrate such points of view. To my opinion, if we perceive the Work level as an aggregation point to serve user interests, it must be relatively unconstrained to introduce a work level. This was also argued for by Richard Smiraglia. ?It would become even more complicated, when, e.g., a new series of R67 related sibling works would appear, because the two wholes can no more form part of a "super" work, because the two were never "conceived at some point in time to form together a logical whole". Obviously, the Work construct, which admits an evolution like a living body, but without loosing any shape it had in the past, cannot be structured based on a simultaneity concept of parthood alone, as I have argued repeatedly in the past. It must necessarily admit temporal parts and synchronous parts, and all mixed forms of asynchronous strands. This, to my memory, was the reason for designing R10, and not the Individual-Complex Work relation only. I think there*must be reasonable* examples proving that R67 alone will not be able to support more complex forms of evolving works. It might quite well be, that the current examples are borderline cases distracting from the real substance. Defining a non-synchronous parthood instead of having a generalization with R10 (i.e., not conceived at some point in time to form together a logical whole) is a dangerous business, because it would be a complement. I think this must be properly discussed. All the best, Martin On 4/4/2022 6:08 AM, Pat Riva via Crm-sig wrote: > Hello all yet again! > > Property R10 > ?has > member (is member of) was discussed in October 2021, during SIG51. And > had been discussed a few times prior to that. However, no vote was > taken at SIG51 and the decision was deferred. We ran out of time to > return to the discussion during SIG52 in February. It is time to take > a vote and move on. > > > The proposal is to deprecated R10 has member (is member of) which > relates two instances of F1 Work. This property is from FRBRoo where > it served to gather and link instances of F14 Individual Work into F15 > Complex Works. All these subclasses of F1 Work have been deprecated in > LRMoo, and furthermore, R10 does not not correspond to any > relationship in LRMer. > > > If the deprecation of R10 is accepted, then it is necessary to adjust > R67 has part (forms part of), linking an instance of F1 Work to a > larger instance of F1 Work, by removing the final paragraph and > modifying its superproperty. > > > Vote *Yes* if you support deprecating R10 (and adjusting R67 in > consequence), vote*No* if you do not, preferably with an explanation. > Indicate *VETO* if you consider this issue needs to be discussed at a SIG. > > > Please vote by *April 10* and I will summarize for the list. > > > a) Current definition of R10 has member (is member of) > > > Domain: _F1_Work > > Range: _F1_Work > > Superproperty of: _F1_Work. R67 has part (is part of): _F1_Work > > Subproperty of: _E89_Propositional Object. _P148_has component (is > component of): _E89_Propositional Object > > Quantification: many to many (0,n:0,n) > > Scope note: This property associates an instance of F1 Work with > another instance of F1 Work that forms a part of it. This property is > transitive. An instance of F1 Work may neither directly nor indirectly > be a member of itself. Instances of F1 Work that are not members of > one another may not share a common member. > > > > b) Current definition of R67 has part (forms part of) > > Domain: _F1_Work > > Range: _F1_Work > > Subproperty of: _F1_Work. R10 has member (is member of): _F1_Work > > Quantification: many to many (0,n:0,n) > > Scope note: This property associates an instance of F1 Work with > another instance of F1 Work that forms part of it in a complementary > role to other sibling parts, conceived at some point in time to form > together a logical whole, such as the parts of a trilogy. This > property is transitive. > > *In contrast, the property /R10 has member (is member of)/may, for > instance, also associate with the overall instance of F1 Work > translations, adaptations and other derivative works that do not form > a logical whole with sibling parts.* > > > Changes for R67 if R10 is deprecated : > > a) Modify superproperty to be the superproperty of the deprecated R10: > > Subproperty of: _E89_Propositional Object. _P148_has component (is > component of): _E89_Propositional Object > > b) Delete the 2^nd paragraph of the scope note. > > In contrast, the property /R10 has member (is member of)/may, for > instance, also associate with the overall instance of F1 Work > translations, adaptations and other derivative works that do not form > a logical whole with sibling parts. > > > > > Pat Riva > Acting University Librarian / Biblioth?caire en chef par int?rim > Concordia University / Universit? Concordia > 1455 de Maisonneuve West, LB-331 > Montr?al, Qu?bec H3G 1M8 > Canada > pat.riva at concordia.ca > > > _______________________________________________ > Crm-sig mailing list > Crm-sig at ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig -- ------------------------------------ Dr. Martin Doerr Honorary Head of the 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 Vox:+30(2810)391625 Email:martin at ics.forth.gr Web-site:http://www.ics.forth.gr/isl -------------- next part -------------- An HTML attachment was scrubbed... URL: From illipmich at gmail.com Tue Apr 5 21:52:33 2022 From: illipmich at gmail.com (Philippe Michon) Date: Tue, 5 Apr 2022 14:52:33 -0400 Subject: [Crm-sig] New Issue: Common Policy / Method for Implementing the .1 Properties of Base and Extensions in RDF In-Reply-To: References: Message-ID: Dear all, I strongly second this proposal. In my opinion, there is a serious lack of guidance as to how we are supposed to use .1 properties. In my opinion, the management of PCs should not only be considered in order to overcome a technological limit. I believe there is some interesting semantics within PCs that would be worth describing more formally. If I'm not mistaken, .1s are only very briefly described in the CRMbase specification. I quickly found only five snippets (I didn't include the new proposals about .1 properties in 7.2.1): 1. In the "Terminology" section under "property": " Properties may themselves have properties that relate to other classes (This feature is used in this model only in order to describe dynamic subtyping of properties)." 2. in the "About the logical expressions used in the CIDOC CRM": "properties of properties, ? .1 properties? are named by ternary predicate symbols; conventionally, we use P14.1 as the ternary predicate symbol corresponding to property P14.1 in the role of. " 3. in the "Extensions of CIDOC CRM": "Existing properties can be extended, either structurally as subproperties, or in some cases, dynamically, using properties of properties which allow subtyping (see section About Types below)." 4. in "Specific Modelling Constructs" under "About Types": "Analogous to the function of the P2 has type (is type of) property, some properties in the CIDOC CRM are associated with an additional property. These are numbered in the CIDOC CRM documentation with a ?.1? extension. The range of these properties of properties always falls under E55 Type. The purpose of a property of a property is to provide an alternative mechanism to specialize its domain property through the use of property subtypes declared as instances of E55 Type. They do not appear in the property hierarchy list but are included as part of the property declarations and referred to in the class declarations. For example, P62.1 mode of depiction: E55 Type is associated with E24 Physical Man-made Thing. P62 depicts (is depicted by): E1 CRM Entity" 5. and in "CIDOC CRM Class Declarations": "Properties of properties are provided indented and in parentheses beneath their respective domain property." My questions and comments: 1. I believe it would be particularly important to clarify if it is possible to use the .1 property of a superproperty with one of its subproperties. For example, is it allowed to use P3.1_has_note with P190_has_symbolic_content? According to my understanding this is not possible, but I do not believe it is explained anywhere. And if it is indeed possible, the PC extension does not allow this semantics. 2. Another issue is the fact that "PC0_Typed_CRM_Property" is not part of the CRMbase class hierarchy. I can understand the reasons behind this choice, but again these would need to be defined. In the context of our work at CHIN, we would sometimes have appreciated using a "P2_has_type" on a PC class in order to type it more formally. Is this something the SIG would encourage? 3. There is also an issue with P67_refers_to and P138_represents. The last is a subproperty of the first and both have a .1 property. In the PC extension, this hierarchy is completely lost, which limits the possibilities of inference. I don't know how to manage this according to CRMpc, but this problem should at least be documented if there is no concrete solution. I don't believe identifying PC138_represents as a subclass of PC67_refers_to would completely resolve this issue. Moreover, this representation would again raise the question concerning the inheritance of .1 properties by subproperties. 4. In the same vein, the question of the relationship that exists between the structure of PCs and their corresponding CRMbase properties is not explicit. If a user wants to implement P67_refers_to and PC67_refers_to in their knowledge graph, how should they implement the whole thing? Should the ontology support this kind of inference (in the RDF), or should it be handled at the query level? 5. I also believe that it would be important to standardize the names of the PC entities. For example, why are the first letters of "PC0_Typed_CRM_Property" capitalized while other classes are not (eg. PC3_has_note)? 6. Now that we formalize the .1 properties, I think it would be more than necessary to have an official scope note for each of them. The vast majority are only very poorly documented in the scope note of their respective property. It is also important to mention that "PC0_Typed_CRM_Property", "P01_has_domain", and "P02_has_range" don't have a scope note at all. 7. It is also difficult to easily find all the information about .1 properties. Would it be useful to have a dedicated section for them in the introduction? Best, Philippe Le jeu. 24 mars 2022 ? 08:51, Martin Doerr via Crm-sig a ?crit : > I think this is a good idea! > > Martin > > On 3/24/2022 1:23 PM, Pavlos Fafalios via Crm-sig wrote: > > Dear George, all, > > The new version of PC classes file (for CRMbase version 7.1.1) has been > already produced (as discussed in the last meeting) and will be soon > available through the crm website (see issue 567 > ). > > Thinking of it again: > Since the namespace for the PC classes is the same with that of the base > classes/properties, why not including them directly within the base RDFS? > (i.e. providing at the end a single rdfs file that also includes the PCs). > Properties of properties are part of the official documentation (of the > base model, or of an extension), so why not including the corresponding PC > classes in the same RDFS file instead of providing and maintaining a second > file? (this applies for both the base model and the extensions) > > This is just a suggestion without knowing any discussions, or decisions > made, when implementing the PC classes for the first time several years ago > (there might be a good reason for having a second file...). > > Best regards, > Pavlos > > On Thu, Mar 24, 2022 at 11:41 AM George Bruseker via Crm-sig < > crm-sig at ics.forth.gr> wrote: > >> Dear all, >> >> Subsequent to another thread I started here I am proposing that there be >> a conversation about having a standard policy and method for creating, >> documenting and making available the .1 properties for base and its >> extensions in the RDF serialization. At present to my knowledge the PC >> classes are only available for CRMBase and relative to version 6.2.1. Other >> extensions however also use .1 constructions and, moreover, CRMbase moves >> forward and its PC classes should hypothetically move with it. Therefore, I >> propose we discuss, create and implement a common policy for creating this >> rdf derivative to support rdf implementations that adopt the .1 >> constructions. >> >> Best, >> >> George >> _______________________________________________ >> Crm-sig mailing list >> Crm-sig at ics.forth.gr >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> > > > -- > Pavlos Fafalios > > Postdoctoral researcher (Marie Curie IF - Project ReKnow > ) > Centre for Cultural Informatics & Information Systems Laboratory > Institute of Computer Science - FORTH > > and > > Visiting Lecturer > Department of Management Science & Technology > Hellenic Mediterranean University > > Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece > Email: fafalios at ics.forth.gr > Tel: +30-2810-391619 > Web: http://users.ics.forth.gr/~fafalios/ > > > _______________________________________________ > Crm-sig mailing listCrm-sig at ics.forth.grhttp://lists.ics.forth.gr/mailman/listinfo/crm-sig > > > > -- > ------------------------------------ > Dr. Martin Doerr > > Honorary Head of the > 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 > > Vox:+30(2810)391625 > Email: martin at ics.forth.gr > Web-site: http://www.ics.forth.gr/isl > > _______________________________________________ > Crm-sig mailing list > Crm-sig at ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > -- *Philippe Michon* (he/il ? https://name.pn/philippe-michon) Semantic Web Analyst Canadian Heritage Information Network (CHIN) Department of Canadian Heritage, Government of Canada 1030 Innes Road, Ottawa (Ontario) K1B 4S7 Philippe.Michon at canada.ca illipmich at gmail.com Tel: 613-998-3721 ext. 225 or 1-800-520-2446 Analyste en web s?mantique R?seau canadien d'information sur le patrimoine (RCIP) Minist?re du Patrimoine canadien, Gouvernement du Canada 1030 chemin Innes, Ottawa (Ontario), K1B 4S7 Philippe.Michon at canada.ca illipmich at gmail.com T?l. : 613-998-3721 poste 225 ou 1-800-520-2446 -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlo.meghini at cnr.it Thu Apr 7 15:40:52 2022 From: carlo.meghini at cnr.it (Carlo Meghini) Date: Thu, 7 Apr 2022 14:40:52 +0200 Subject: [Crm-sig] representing textual phenomena Message-ID: <5d8557b3-2eae-29f0-4c3e-264651922f18@cnr.it> Hi, I'm working on the representation of literary works (LWs) using the CRM core and the LRMoo. I've made every LW, or any part of it, an instance of both E33_Linguistic_Object and F2_Expression. I'm interested in describing the syntactic structure of a LW, so by "part" I do not mean just chapters and sections, but also sentences, clauses, syntagmata and words; and I have compositional properties of coordination and subordination. Now I need to describe the fact that any part of a LW occurs within the text in several segments (some sentences are in fact broken in 2, 3 or even 4 segments), and the position of each segment within the LW. This is very similary to the situation where there is a global event (such as the execution of a piano concerto) which has one sub-event (such as a specific instrument playing) occurring in several time intervals. The difference is that these occurrences are not in the relative time of the concerto, but in the relative space of a LW. I've made these segments instance of class TextFragment, a subclass of E33 but not of F2 because a fragment may be as small as a word or two. The property linking a part to the text fragments where it occurs is called "occursIn". Now my first question is (assuming the modeling is ok), where should I hook such property in the CRM property taxonomy? The property linking a text fragment to the actual text is P190_has_symbolic_content. I guess this is rather uncontroversial. Finally, the position of each text fragment within the LW must be represented. This is done by using 2 properties, one for the beginning and one for the ending of the fragment. The value of each property is a position within the text. A position, in turn, is identified by 2 coordinates: the content unit where it occurs (e.g., chapter) and by a number giving the offset within the content unit. Final question: where would position, begining and ending position belong in the CRM? Thank you for your time. Carlo -- Carlo Meghini Istituto di Scienza e Tecnologie dell'Informazione [ISTI] Consiglio Nazionale delle Ricerche [CNR] Area della Ricerca di Pisa Via G. Moruzzi 1, 56124 Pisa From fafalios at ics.forth.gr Thu Apr 7 17:59:37 2022 From: fafalios at ics.forth.gr (Pavlos Fafalios) Date: Thu, 7 Apr 2022 17:59:37 +0300 Subject: [Crm-sig] New Issue: Common Policy / Method for Implementing the .1 Properties of Base and Extensions in RDF In-Reply-To: References: Message-ID: Dear Philippe, Thank you for the interesting discussion. Here is my understanding: (note: I was not involved when the PCs were first introduced) On Tue, Apr 5, 2022 at 9:52 PM Philippe Michon via Crm-sig < crm-sig at ics.forth.gr> wrote: > Dear all, > > I strongly second this proposal. In my opinion, there is a serious lack of > guidance as to how we are supposed to use .1 properties. In my opinion, the > management of PCs should not only be considered in order to overcome a > technological limit. I believe there is some interesting semantics within > PCs that would be worth describing more formally. > > If I'm not mistaken, .1s are only very briefly described in the CRMbase > specification. I quickly found only five snippets (I didn't include the new > proposals about .1 properties in 7.2.1): > > 1. > > In the "Terminology" section under "property": " Properties may > themselves have properties that relate to other classes (This feature is > used in this model only in order to describe dynamic subtyping of > properties)." > 2. > > in the "About the logical expressions used in the CIDOC CRM": > "properties of properties, ? .1 properties? are named by ternary predicate > symbols; conventionally, we use P14.1 as the ternary predicate symbol > corresponding to property P14.1 in the role of. " > 3. > > in the "Extensions of CIDOC CRM": "Existing properties can be > extended, either structurally as subproperties, or in some cases, > dynamically, using properties of properties which allow subtyping (see > section About Types below)." > 4. > > in "Specific Modelling Constructs" under "About Types": "Analogous to > the function of the P2 has type (is type of) property, some properties in > the CIDOC CRM are associated with an additional property. These are > numbered in the CIDOC CRM documentation with a ?.1? extension. The range of > these properties of properties always falls under E55 Type. The purpose of > a property of a property is to provide an alternative mechanism to > specialize its domain property through the use of property subtypes > declared as instances of E55 Type. They do not appear in the property > hierarchy list but are included as part of the property declarations and > referred to in the class declarations. For example, P62.1 mode of > depiction: E55 Type is associated with E24 Physical Man-made Thing. P62 > depicts (is depicted by): E1 CRM Entity" > 5. > > and in "CIDOC CRM Class Declarations": "Properties of properties are > provided indented and in parentheses beneath their respective domain > property." > > My questions and comments: > > 1. > > I believe it would be particularly important to clarify if it is > possible to use the .1 property of a superproperty with one of its > subproperties. For example, is it allowed to use P3.1_has_note with > P190_has_symbolic_content? According to my understanding this is not > possible, but I do not believe it is explained anywhere. And if it is > indeed possible, the PC extension does not allow this semantics. > 2. > > Another issue is the fact that "PC0_Typed_CRM_Property" is not part of > the CRMbase class hierarchy. I can understand the reasons behind this > choice, but again these would need to be defined. In the context of our > work at CHIN, we would sometimes have appreciated using a "P2_has_type" on > a PC class in order to type it more formally. Is this something the SIG > would encourage? > > CIDOC-CRM is an ontology which can be implemented in different ways, one of these being RDF (the main one). However, RDF does not support a direct way to express properties of properties (one important limitation), so the PCs just provide a way to enable their representation and querying. So, as I see it, PC0_Typed_CRM_Property must not be part of the official documentation since it has to do with the implementation of the model in a particular language / data model (and is also out of the universe of crm's discourse). Using 'P2 has type' for a PC seems strange (but interesting) to me, because the .1 properties are actually used for providing such a type to a property. Could you please give a particular example? > > 1. > > There is also an issue with P67_refers_to and P138_represents. The > last is a subproperty of the first and both have a .1 property. In the PC > extension, this hierarchy is completely lost, which limits the > possibilities of inference. I don't know how to manage this according to > CRMpc, but this problem should at least be documented if there is no > concrete solution. I don't believe identifying PC138_represents as a > subclass of PC67_refers_to would completely resolve this issue. Moreover, > this representation would again raise the question concerning the > inheritance of .1 properties by subproperties. > > As I see it, we cannot have the PC class of a property in a dataset without also having the actual property (since we want to assign a triple to that property). So, inference can be done using the actual properties and their subproperty relation, not the PCs which are just used for enabling the representation and querying of a property of property. Do you have in mind a particular reasoning scenario which requires clear semantics between the PC classes and not the properties? > > 1. > > In the same vein, the question of the relationship that exists between > the structure of PCs and their corresponding CRMbase properties is not > explicit. If a user wants to implement P67_refers_to and PC67_refers_to in > their knowledge graph, how should they implement the whole thing? Should > the ontology support this kind of inference (in the RDF), or should it be > handled at the query level? > > Not sure I understand the question correctly. To my understanding, PCs just provide syntactic sugar for representing properties of properties. They are used in parallel with the corresponding properties when we want to express a property of property. So, it seems to be a problem/task of data generation or/and data querying. E.g., an example of a dataset: :visual_item1 crm:P67_refers_to :e1 :PC67_inst1 a crm:PC67_refers_to ; crm:P01_has_domain :visual_item1 ; crm:P02_has_range :e1 ; crm:P67.1_has_type . and an example of a query for getting the references of visual items and their type: SELECT ?visual_item ?reference ?type WHERE { ?visual_item crm:P67_refers_to :reference . ?x crm:P01_has_domain ?visual_item ; crm:P02_has_range ?reference ; crm:P67.1_has_type ?type } Do you have in mind a particular inference scenario that requires clear semantics between :P67_refers_to and instances of crm:PC67_refers_to? (I think one will have to implement their own reasoner even if clear semantics are added). > > 1. > > I also believe that it would be important to standardize the names of > the PC entities. For example, why are the first letters of > "PC0_Typed_CRM_Property" capitalized while other classes are not (eg. > PC3_has_note)? > > A possible explanation: The first letters of the property classes are not capitalized because the first letters of the corresponding CRM properties are not capitalized (contrary to the CRM classes whose words are capitalized). > > 1. > > Now that we formalize the .1 properties, I think it would be more than > necessary to have an official scope note for each of them. The vast > majority are only very poorly documented in the scope note of their > respective property. It is also important to mention that > "PC0_Typed_CRM_Property", "P01_has_domain", and "P02_has_range" don't have > a scope note at all. > > I agree. Descriptions are needed within the RDF file, as well as a clear example on how one can use them when creating or querying a dataset. Best regards, Pavlos > > 1. > > It is also difficult to easily find all the information about .1 > properties. Would it be useful to have a dedicated section for them in the > introduction? > > Best, > > Philippe > > > Le jeu. 24 mars 2022 ? 08:51, Martin Doerr via Crm-sig < > crm-sig at ics.forth.gr> a ?crit : > >> I think this is a good idea! >> >> Martin >> >> On 3/24/2022 1:23 PM, Pavlos Fafalios via Crm-sig wrote: >> >> Dear George, all, >> >> The new version of PC classes file (for CRMbase version 7.1.1) has been >> already produced (as discussed in the last meeting) and will be soon >> available through the crm website (see issue 567 >> ). >> >> Thinking of it again: >> Since the namespace for the PC classes is the same with that of the base >> classes/properties, why not including them directly within the base RDFS? >> (i.e. providing at the end a single rdfs file that also includes the PCs). >> Properties of properties are part of the official documentation (of the >> base model, or of an extension), so why not including the corresponding PC >> classes in the same RDFS file instead of providing and maintaining a second >> file? (this applies for both the base model and the extensions) >> >> This is just a suggestion without knowing any discussions, or decisions >> made, when implementing the PC classes for the first time several years ago >> (there might be a good reason for having a second file...). >> >> Best regards, >> Pavlos >> >> On Thu, Mar 24, 2022 at 11:41 AM George Bruseker via Crm-sig < >> crm-sig at ics.forth.gr> wrote: >> >>> Dear all, >>> >>> Subsequent to another thread I started here I am proposing that there be >>> a conversation about having a standard policy and method for creating, >>> documenting and making available the .1 properties for base and its >>> extensions in the RDF serialization. At present to my knowledge the PC >>> classes are only available for CRMBase and relative to version 6.2.1. Other >>> extensions however also use .1 constructions and, moreover, CRMbase moves >>> forward and its PC classes should hypothetically move with it. Therefore, I >>> propose we discuss, create and implement a common policy for creating this >>> rdf derivative to support rdf implementations that adopt the .1 >>> constructions. >>> >>> Best, >>> >>> George >>> _______________________________________________ >>> Crm-sig mailing list >>> Crm-sig at ics.forth.gr >>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >>> >> >> >> -- >> Pavlos Fafalios >> >> Postdoctoral researcher (Marie Curie IF - Project ReKnow >> ) >> Centre for Cultural Informatics & Information Systems Laboratory >> Institute of Computer Science - FORTH >> >> and >> >> Visiting Lecturer >> Department of Management Science & Technology >> Hellenic Mediterranean University >> >> Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece >> Email: fafalios at ics.forth.gr >> Tel: +30-2810-391619 >> Web: http://users.ics.forth.gr/~fafalios/ >> >> >> _______________________________________________ >> Crm-sig mailing listCrm-sig at ics.forth.grhttp://lists.ics.forth.gr/mailman/listinfo/crm-sig >> >> >> >> -- >> ------------------------------------ >> Dr. Martin Doerr >> >> Honorary Head of the >> 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 >> >> Vox:+30(2810)391625 >> Email: martin at ics.forth.gr >> Web-site: http://www.ics.forth.gr/isl >> >> _______________________________________________ >> Crm-sig mailing list >> Crm-sig at ics.forth.gr >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> > > > -- > > *Philippe Michon* > > (he/il ? https://name.pn/philippe-michon) > > > Semantic Web Analyst > Canadian Heritage Information Network (CHIN) > Department of Canadian Heritage, Government of Canada > 1030 Innes Road, Ottawa (Ontario) K1B 4S7 > Philippe.Michon at canada.ca > > illipmich at gmail.com > Tel: 613-998-3721 ext. 225 or 1-800-520-2446 > > Analyste en web s?mantique > R?seau canadien d'information sur le patrimoine (RCIP) > Minist?re du Patrimoine canadien, Gouvernement du Canada > 1030 chemin Innes, Ottawa (Ontario), K1B 4S7 > Philippe.Michon at canada.ca > > illipmich at gmail.com > T?l. : 613-998-3721 poste 225 ou 1-800-520-2446 > _______________________________________________ > Crm-sig mailing list > Crm-sig at ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > -- Pavlos Fafalios Postdoctoral researcher (Marie Curie IF - Project ReKnow ) Centre for Cultural Informatics & Information Systems Laboratory Institute of Computer Science - FORTH and Visiting Lecturer Department of Management Science & Technology Hellenic Mediterranean University Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece Email: fafalios at ics.forth.gr Tel: +30-2810-391619 Web: http://users.ics.forth.gr/~fafalios/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at ics.forth.gr Thu Apr 7 20:20:12 2022 From: martin at ics.forth.gr (Martin Doerr) Date: Thu, 7 Apr 2022 20:20:12 +0300 Subject: [Crm-sig] New Issue: Common Policy / Method for Implementing the .1 Properties of Base and Extensions in RDF In-Reply-To: References: Message-ID: <24e3ee67-b889-8208-d8fb-184d1d6b8f1c@ics.forth.gr> Dear Philippe, all, I agree with Pavlos' explanations. The PC classes are not an ontological construct. They are not CRM Entities, and therefore P2_has_type does not apply. I do not think Scope Notes in the sense we use in the CRM are required for PC0_Typed_CRM_Property", "P01_has_domain", and "P02_has_range". We need just logical definitions, and use guidelines. We use "scope notes" to make the connection between logical ontological constructs and the users' cognitive anticipation of reality. I'd prefer to add a textual "*Definition*". They are exclusively implementation constructs for simulating ternary relations in RDF. Some other KR languages can represent them properly. Therefore, any individual definition should be a "mechanical" product of the overall definition of the PC class construct and the scope note part of the .1 property in the CRM. I'd agree that scope note parts for .1 properties may be better, more clearly marked in the CRM Definition. The question of .1 property inheritance is interesting. I think it is just a question of the reasoning rules with the PC classes to define the inheritance.? In general, I maintain a kind of equivalence of subproperties with .1 properties describing a type, as we do for classes and P2 has type, and I think this is clearly explained in the Introduction Section "About Types". If this needs more or better wording, this is a particular issue to be discussed. I agree that this equivalence and inheritance need to be examined formally. All the best, Martin On 4/7/2022 5:59 PM, Pavlos Fafalios wrote: > Dear Philippe, > > Thank you for the interesting discussion. > > Here is my understanding: (note: I was not involved?when the PCs were > first introduced) > > On Tue, Apr 5, 2022 at 9:52 PM Philippe Michon via Crm-sig > wrote: > > Dear all, > > I strongly second this proposal. In my opinion, there is a serious > lack of guidance as to how we are supposed to use .1 properties. > In my opinion, the management of PCs should not only be considered > in order to overcome a technological limit. I believe there is > some interesting semantics within PCs that would be worth > describing more formally. > > If I'm not mistaken, .1s are only very briefly described in the > CRMbase specification. I quickly found only five snippets (I > didn't include the new proposals about .1 properties in 7.2.1): > > 1. > > In the "Terminology" section under "property": " Properties > may themselves have properties that relate to other classes > (This feature is used in this model only in order to describe > dynamic subtyping of properties)." > > 2. > > in the "About the logical expressions used in the CIDOC CRM": > "properties of properties, ? .1 properties? are named by > ternary predicate symbols; conventionally, we use P14.1 as the > ternary predicate symbol corresponding to property P14.1 in > the role of. " > > 3. > > in the "Extensions of CIDOC CRM": "Existing properties can be > extended, either structurally as subproperties, or in some > cases, dynamically, using properties of properties which allow > subtyping (see section About Types below)." > > 4. > > in "Specific Modelling Constructs" under "About Types": > "Analogous to the function of the P2 has type (is type of) > property, some properties in the CIDOC CRM are associated with > an additional property. These are numbered in the CIDOC CRM > documentation with a ?.1? extension. The range of these > properties of properties always falls under E55 Type. The > purpose of a property of a property is to provide an > alternative mechanism to specialize its domain property > through the use of property subtypes declared as instances of > E55 Type. They do not appear in the property hierarchy list > but are included as part of the property declarations and > referred to in the class declarations. For example, P62.1 mode > of depiction: E55 Type is associated with E24 Physical > Man-made Thing. P62 depicts (is depicted by): E1 CRM Entity" > > 5. > > and in "CIDOC CRM Class Declarations": "Properties of > properties are provided indented and in parentheses beneath > their respective domain property." > > My questions and comments: > > 1. > > I believe it would be particularly important to clarify if it > is possible to use the .1 property of a superproperty with one > of its subproperties. For example, is it allowed to use > P3.1_has_note with P190_has_symbolic_content? According to my > understanding this is not possible, but I do not believe it is > explained anywhere. And if it is indeed possible, the PC > extension does not allow this semantics. > > 2. > > Another issue is the fact that "PC0_Typed_CRM_Property" is not > part of the CRMbase class hierarchy. I can understand the > reasons behind this choice, but again these would need to be > defined. In the context of our work at CHIN, we would > sometimes have appreciated using a "P2_has_type" on a PC class > in order to type it more formally. Is this something the SIG > would encourage? > > > CIDOC-CRM is an ontology which can be implemented in different ways, > one of these being RDF (the main one). However, RDF does not support a > direct way to express properties of properties (one important > limitation), so the PCs just provide a way to enable their > representation and querying.?So, as I see it, PC0_Typed_CRM_Property > must not be part of the official documentation since it has to do with > the implementation of the model in a particular language / data model > (and is also out of the universe of crm's discourse). > Using 'P2 has type' for a PC seems strange (but interesting) to me, > because the .1 properties are actually used for providing such a type > to a property. Could you please give a particular example? > > 1. > > There is also an issue with P67_refers_to and P138_represents. > The last is a subproperty of the first and both have a .1 > property. In the PC extension, this hierarchy is completely > lost, which limits the possibilities of inference. I don't > know how to manage this according to CRMpc, but this problem > should at least be documented if there is no concrete > solution. I don't believe identifying PC138_represents as a > subclass of PC67_refers_to would completely resolve this > issue. Moreover, this representation would again raise the > question concerning the inheritance of .1 properties by > subproperties. > > > As I see it, we cannot have the PC class of a property in a dataset > without also having the actual property (since we want to assign a > triple to that property). So, inference can be done using the actual > properties and their subproperty relation, not the PCs which are just > used for enabling the representation and querying of a property of > property. > Do you have in mind a particular reasoning scenario which requires > clear semantics between the PC classes and not the properties? > > 1. > > In the same vein, the question of the relationship that exists > between the structure of PCs and their corresponding CRMbase > properties is not explicit. If a user wants to implement > P67_refers_to and PC67_refers_to in their knowledge graph, how > should they implement the whole thing? Should the ontology > support this kind of inference (in the RDF), or should it be > handled at the query level? > > > Not sure I understand the question correctly. To my understanding, PCs > just provide syntactic sugar for representing properties of > properties. They are used in parallel with the corresponding > properties when we want to express a property of property. So, it > seems to be a problem/task of data generation or/and data querying. > E.g., an example of a dataset: > > :visual_item1 crm:P67_refers_to :e1 > :PC67_inst1 a crm:PC67_refers_to ; > ? ? ? ? ? ? crm:P01_has_domain?:visual_item1 ; > ? ? ? ? ? ? crm:P02_has_range :e1 ; > ? ? ? ? ? ? crm:P67.1_has_type? . > > and an example of a query for getting the references of visual items > and their type: > > SELECT ?visual_item ?reference ?type?WHERE { > ? ??visual_item crm:P67_refers_to :reference . > ? ??x crm:P01_has_domain??visual_item ; > crm:P02_has_range ?reference ; > crm:P67.1_has_type ?type } > > Do you have in mind a particular inference scenario that requires > clear semantics between :P67_refers_to and instances of > crm:PC67_refers_to? (I think one will have to implement their own > reasoner even if clear semantics are added). > > 1. > > I also believe that it would be important to standardize the > names of the PC entities. For example, why are the first > letters of "PC0_Typed_CRM_Property" capitalized while other > classes are not (eg. PC3_has_note)? > > > A possible explanation: The first letters of the property classes are > not capitalized because the first letters of the corresponding CRM > properties are not capitalized (contrary to the CRM classes whose > words are capitalized). > > 1. > > Now that we formalize the .1 properties, I think it would be > more than necessary to have an official scope note for each of > them. The vast majority are only very poorly documented in the > scope note of their respective property. It is also important > to mention that "PC0_Typed_CRM_Property", "P01_has_domain", > and "P02_has_range" don't have a scope note at all. > > > I agree. Descriptions are needed within the RDF file, as well as a > clear example on how one can use them when?creating or querying a > dataset. > > Best regards, > Pavlos > > 1. > > It is also difficult to easily find all the information about > .1 properties. Would it be useful to have a dedicated section > for them in the introduction? > > Best, > > Philippe > > > > Le?jeu. 24 mars 2022 ??08:51, Martin Doerr via Crm-sig > a ?crit?: > > I think this is a good idea! > > Martin > > On 3/24/2022 1:23 PM, Pavlos Fafalios via Crm-sig wrote: >> Dear George, all, >> >> The new version of PC classes file (for CRMbase version >> 7.1.1) has been already produced (as discussed in the last >> meeting) and will be soon available through the crm website >> (see issue 567 >> ). >> >> Thinking of it again: >> Since the namespace for the PC classes is the same with that >> of the base classes/properties, why not including them >> directly within?the base RDFS? (i.e. providing at the end a >> single rdfs file that also includes the PCs). >> Properties of properties?are part of the official >> documentation (of the base model, or of an extension), so why >> not including the corresponding PC classes in the same RDFS >> file instead of providing and maintaining a second file? >> (this applies for both the base model and the extensions) >> >> This is just a suggestion without knowing any discussions,?or >> decisions made, when implementing the PC classes for the >> first time several years ago (there might be a good reason >> for having a second file...). >> >> Best regards, >> Pavlos >> >> On Thu, Mar 24, 2022 at 11:41 AM George Bruseker via Crm-sig >> wrote: >> >> Dear all, >> >> Subsequent to another thread I started here I am >> proposing that there be a conversation about having a >> standard policy and method for creating, documenting and >> making available the .1 properties for base and its >> extensions in the RDF serialization. At present to my >> knowledge the PC classes are only available for CRMBase >> and relative to version 6.2.1. Other extensions however >> also use .1 constructions and, moreover, CRMbase moves >> forward and its PC classes should hypothetically move >> with it. Therefore, I propose we discuss, create and >> implement a common policy for creating this rdf >> derivative to support rdf implementations?that adopt the >> .1 constructions. >> >> Best, >> >> George >> _______________________________________________ >> Crm-sig mailing list >> Crm-sig at ics.forth.gr >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> >> >> >> -- >> Pavlos Fafalios >> >> Postdoctoral researcher (Marie Curie IF - Project ReKnow >> ) >> Centre for Cultural Informatics & Information Systems Laboratory >> Institute of Computer Science -?FORTH >> and >> >> Visiting Lecturer >> Department of Management Science & Technology >> Hellenic Mediterranean University >> >> Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, >> Greece >> Email: fafalios at ics.forth.gr >> Tel: +30-2810-391619 >> Web: http://users.ics.forth.gr/~fafalios/ >> >> >> _______________________________________________ >> Crm-sig mailing list >> Crm-sig at ics.forth.gr >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > > -- > ------------------------------------ > Dr. Martin Doerr > > Honorary Head of the > 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 > > Vox:+30(2810)391625 > Email:martin at ics.forth.gr > Web-site:http://www.ics.forth.gr/isl > > _______________________________________________ > Crm-sig mailing list > Crm-sig at ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > > > -- > > *Philippe Michon* > > (he/il ? https://name.pn/philippe-michon > )** > > > Semantic Web Analyst > Canadian Heritage Information Network (CHIN) > Department of Canadian Heritage, Government of Canada > 1030 Innes Road, Ottawa (Ontario) K1B 4S7 > Philippe.Michon at canada.ca > > illipmich at gmail.com > Tel: 613-998-3721 ext. 225 or 1-800-520-2446 > > Analyste en web s?mantique > R?seau canadien d'information sur le patrimoine (RCIP) > Minist?re du Patrimoine canadien, Gouvernement du Canada > 1030 chemin Innes, Ottawa (Ontario), K1B 4S7 > Philippe.Michon at canada.ca > > illipmich at gmail.com > T?l. : 613-998-3721 poste 225 ou 1-800-520-2446 > > _______________________________________________ > Crm-sig mailing list > Crm-sig at ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > > > > -- > Pavlos Fafalios > > Postdoctoral researcher (Marie Curie IF - Project ReKnow > ) > Centre for Cultural Informatics & Information Systems Laboratory > Institute of Computer Science -?FORTH > and > > Visiting Lecturer > Department of Management Science & Technology > Hellenic Mediterranean University > > Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece > Email: fafalios at ics.forth.gr > Tel: +30-2810-391619 > Web: http://users.ics.forth.gr/~fafalios/ > -- ------------------------------------ Dr. Martin Doerr Honorary Head of the 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 Vox:+30(2810)391625 Email:martin at ics.forth.gr Web-site:http://www.ics.forth.gr/isl -------------- next part -------------- An HTML attachment was scrubbed... URL: From ctl at fe.up.pt Fri Apr 8 23:53:56 2022 From: ctl at fe.up.pt (Carla Teixeira Lopes) Date: Fri, 8 Apr 2022 21:53:56 +0100 Subject: [Crm-sig] LinkedArchives @ TPDL 2022: call for contributions Message-ID: We are thrilled to announce that the 2nd edition of the International Workshop on Archives and Linked Data (https://linkedarchives.inesctec.pt/) will be run in conjunction with the 26th International Conference on Theory and Practice of Digital Libraries (TPDL 2022) (http://tpdl2022.dei.unipd.it/ ). The workshop aims to gather researchers and specialists who are engaged in initiatives that cross Archives and the Semantic Web and those planning similar initiatives in cultural heritage organizations. We'd love to have your contributions, so please take a look at the call: https://linkedarchives.inesctec.pt/#submission. Please note that *29 May 2022* is the submission deadline. The workshop will include invited talks, presentations of papers and demos, as well as an opportunity for participants to meet and discuss latest developments and opportunities in the field. TPDL 2022 aims to be an in-presence event in Padua, Italy. TPDL will publish the proceedings of the workshops and the doctoral consortium in the CEUR Workshop Series . Extended versions of the best papers will be selected to be published in the ACM Journal on Computing and Cultural Heritage (JOCCH). We look forward to receiving your submissions and seeing you in September! Best regards, Carla Teixeira Lopes (on behalf of the Organizing Committee) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsoulouha at ics.forth.gr Mon Apr 18 12:54:10 2022 From: tsoulouha at ics.forth.gr (Eleni Tsoulouha) Date: Mon, 18 Apr 2022 12:54:10 +0300 Subject: [Crm-sig] 54th CIDOC CRM and 47th FRBR CRM meeting (September, 2022; Rome) Message-ID: <86afbe83-b7ee-959f-96a8-8d6bb91b3666@ics.forth.gr> Dear all, Please see below for the provisional programme of the *54th CIDOC CRM and 47th FRBR CRM meeting in September in Rome*. The detailed and final programme will be confirmed during the summer. *Location:* Faculty of Architecture, piazza Borghese 9, Rome *Tue 13 Sep * 13:30-14:00: Registration 14:00-14:30: Welcome from Sapienza 14:30-16:00: CRM SIG Presentations 16:00-16:30: Break 16:30-18:00: CRM core *Wed 14 Sep* 09:30-11:00: FRBR 11:00-11:30: Coffee Break 11:30-13:00: FRBR 13:00-14:30: Lunch break 14:30-16:00: FRBR 16:00-16:30: Coffee Break 16:30-18:00: Community *Thu 15 Sep * 09:30-11:00: CRM core 11:00-11:30: Coffee Break 11:30-13:00: CRM core 13:00-14:30: Lunch break 14:30-16:00: Extensions 16:00-16:30: Coffee Break 16:30-18:00: Extensions * **Fri 16 Sep * 09:30-10:15: Martin Doerr: CIDOC-CRM and its extensions: final balance on the CIDOC CRM SIG in Rome 10:15-11:00: George Bruseker: Sharing Knowledge of our pasts: a practical look on the application and future potentialities of semantic data 11:00-11:30: Coffee Break 11:30-14:00: Round table: Interoperability and Ontologies (SIG + Stefano Della Torre, Politecnico di Milano; Donatella Fiorani, Sapienza Universit? di Roma, Stefano Francesco Musso, University of Genoa; Marco Pretelli, University of Bologna 'Alma Mater') **_ _** **_Options for discounted accommodation: _ ** *Sapienza Guest House, via Volturno **42, Rome *(https://www.uniroma1.it/en/pagina/sapienza-guest-house). _Prices_ (per night, with reservation made through the Department): - single room ? 50.00 - double room used by a single person ? 60.00 - double room used by two persons ? 65.00 - double room ? 75.00 (with frescoes) - studio flat ? 80.00 The total rooms in the Guest House are 38. The deadline for booking accommodation is the 15th of May. *Please contact Donatella and Marta* (cc in the email)***directly.* All the best, Eleni* * -------------- next part -------------- An HTML attachment was scrubbed... URL: From c.e.s.ore at iln.uio.no Wed Apr 20 15:50:38 2022 From: c.e.s.ore at iln.uio.no (Christian-Emil Smith Ore) Date: Wed, 20 Apr 2022 12:50:38 +0000 Subject: [Crm-sig] =?windows-1252?q?Most_for_entertainment=3A_Example_of_A?= =?windows-1252?q?7_Embedding=2C_BBC_documentary_-San_Galgano=92s_sword?= Message-ID: <7d398ea4906a41129fdb1e30ccd11771@iln.uio.no> A7 Embedding San Galgano?s sword embedded at the Hermitage of Monte Siepi, [He retired around 1170 to live as a hermit. as a symbol of peace he embedded his sword in a stone, which can still be seen today] (https://en.wikipedia.org/wiki/Galgano_Guidotti) BBC has a documentary about the sword: https://www.bbc.com/reel/video/p0c1ymsq/the-truth-behind-the-legend-of-the-sword-in-the-stone- Christian-Emil -------------- next part -------------- An HTML attachment was scrubbed... URL: From pat.riva at concordia.ca Thu Apr 21 05:41:52 2022 From: pat.riva at concordia.ca (Pat Riva) Date: Thu, 21 Apr 2022 02:41:52 +0000 Subject: [Crm-sig] LRMoo: review of properties--request for comments Message-ID: Hello all, The LRMoo WG has done a review of technical aspects of the LRMoo property definitions. Namely, quantifiers, as well as transitivity, symmetry, reflexivity as discussed in recent SIGs for CRMbase. We have found some cases of questionable quantifiers. Finally, we reviewed the handling of the .1 properties, based on the best practices recently discussed on the list. At this point we'd appreciate anyone who would have time to review our conclusions. These are found in a 3 page document here: https://docs.google.com/document/d/1u7bjA8ttGHGXRQ04PaYSGzsicyMpzc_PD_aQj5cDyx4/edit?usp=sharing This request for comments is open until May 14 (that is until after the upcoming SIG meeting). Many thanks, Pat Pat Riva Acting University Librarian / Biblioth?caire en chef par int?rim Concordia University / Universit? Concordia 1455 de Maisonneuve West, LB-331 Montr?al, Qu?bec H3G 1M8 Canada pat.riva at concordia.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: From pat.riva at concordia.ca Thu Apr 21 06:57:15 2022 From: pat.riva at concordia.ca (Pat Riva) Date: Thu, 21 Apr 2022 03:57:15 +0000 Subject: [Crm-sig] Call for e-vote: LRMoo, F56 Externalization Event Message-ID: Hello all, Continuing the series of LRMoo e-votes relating to topics previously discussed at SIG meetings but not voted on. This discussion was held during the October 2021 SIG without a formal vote, but there seemed to be consensus. Proposal: Deprecate the class F56 Externalization Event, and its property Rnn was remembered in (is memory of). Remark on status: F56 was approved, but only in LRMoo and so has never been implemented. Rnn was never fully approved or numbered. Its superproperty is not determined and none of the examples previously proposed have been approved. Thus, it may not be quite correct to say these are being deprecated, rather they are being withdrawn? Reasoning: F56 was conceived as a node to bring together the classes F28 Expression Creation and F31 Performance and express their generalization. This is not essential as, eventually, both classes do meet at E7 Activity. The only property of F56 is the (incomplete) Rnn which only expresses a generalization of the R17 property linking an expression creation to an expression. If you agree, vote Yes. If you disagree vote No, preferably with an explanation. To refer the discussion to a future SIG meeting, vote VETO. Please vote by April 27, at which point I will summarize for the list. If yes, these editorial modifications also follow: * Changing superclass of F31 Performance back to E7 Activity (the superclass as it was in FRBRoo v.2.4). * Removing F56 from the list of superclasses of F28 Expression Creation, leaving E12 Production and E65 Creation. * Removing Rnn as the superproperty of R17 created (was created by) [D: F28; R: F2], leaving just P94 has created (was created by) [D: E65; R: E28] as the superproperty. For reference, the latest versions of the definitions of F56 and Rnn: F56 Externalization Event Subclass of: E7 Activity Superclass of: F28 Expression Creation F31 Performance Scope note: This class comprises activities that produce signs or sensory impressions as organized and complete wholes, typically intended to be received, in this completeness, by some audience, either directly via their senses or via persistent media at some later time. It comprises in particular novel externalizations of thought ? art in all forms ? including rendering existing expressions such as musical scores, theatre plays, scripts or texts, in a particular manner, including through the performing arts, writing or other methods of externalization. Examples: * the creation of the original manuscript score ?Uwertura tragicna? by Andrej Panufnik in Warsaw (F28) * the reconstruction from memory of the manuscript score ?Uwertura tragicna? by Andrej Panufnik in 1945 after the original score was destroyed during the war (F28) * performing the ballet entitled ?Rite of Spring?, as choreographed by Pina Bausch, in Avignon, at the Popes? Palace, on July 7, 1995 [individual performance] (F31) * performing the operatic work entitled ?Dido and Aeneas?, as directed by Edward Gordon Craig and conducted by Martin Shaw, in London, Hampstead Conservatoire, on May 17, 18, and 19, 1900 [run of performances] (F31) Properties: Rnn3 was remembered in (is memory of): F2 Expression Rnn3 was remembered in (contains memory of) Domain: F56 Externalization Event Range: F2 Expression Subproperty of: E1 CRM Entity. P67i is referred to by: E89 Propositional Object [or may be Out of CIDOC CRM Scope?] Superproperty of: F28 Expression Creation. R17 created (was created by): F2 Expression Quantification: many to many, necessary, dependent (1,n:1,n) Scope note: This property associates an instance of F56 Externalization Event with the instance of F2 Expression that records or refers to the content of that particular externalization event, in whole or in part. This recording may be done either directly or be transferred through tradition. The expression that records the externalization event may or may not be an expression of the work that was externalized in the event. [No approved examples] Pat Riva Acting University Librarian / Biblioth?caire en chef par int?rim Concordia University / Universit? Concordia 1455 de Maisonneuve West, LB-331 Montr?al, Qu?bec H3G 1M8 Canada pat.riva at concordia.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at ics.forth.gr Thu Apr 21 16:01:34 2022 From: martin at ics.forth.gr (Martin Doerr) Date: Thu, 21 Apr 2022 16:01:34 +0300 Subject: [Crm-sig] Call for e-vote: LRMoo, F56 Externalization Event In-Reply-To: References: Message-ID: <03df1ae7-d53f-5134-8afb-524737a44c26@ics.forth.gr> //I vote YES. Comment: F56 is a very important concept intellectually, but probably too abstract.? There is a question if this generalization could be saved somewhere else. /Rnn was remembered in (is memory of)/ actually means that someone produced this memory. I would rather propose a another property directly of F28: /Rnn included a memory of/: E7 Activity.? This is probably much more useful than the Recording stuff we have discussed, is specific to the author, and would help use with the missing documentation activity in CRMbase. It would also help with recording of oral traditions. "/Rnn included a memory of/:" should be restricted to physical witnesses of the event (or via recording devices). Best, Martin On 4/21/2022 6:57 AM, Pat Riva via Crm-sig wrote: > Hello all, > > Continuing the series of LRMoo e-votes relating to topics previously > discussed at SIG meetings but not voted on. This discussion was held > during the October 2021 SIG without a formal vote, but there seemed to > be consensus. > > *Proposal:* Deprecate the class F56 Externalization Event, and its > property Rnn was remembered in (is memory of). > > > *Remark on status:*?F56 was approved, but only in LRMoo and so has > never been implemented. > > Rnn was never fully approved or numbered. Its superproperty is not > determined and none of the examples previously proposed have been > approved. > > Thus, it may not be quite correct to say these are being deprecated, > rather they are being withdrawn? > > *Reasoning*: F56 was conceived as a node to bring together the classes > F28 Expression Creation and F31 Performance and express their > generalization. This is not essential as, eventually, both classes do > meet at E7 Activity. The only property of F56 is the (incomplete) Rnn > which only expresses a generalization of the R17 property linking an > expression creation to an expression. > > > If you agree, vote *Yes*. If you disagree vote *No*, preferably with > an explanation. > > To refer the discussion to a future SIG meeting, vote *VETO*. > > Please vote by *April 27*, at which point I will summarize for the list. > > > If yes, these editorial modifications also follow: > > * > > Changing superclass of F31 Performance back to E7 Activity (the > superclass as it was in FRBRoo v.2.4). > > * > > Removing F56 from the list of superclasses of F28 Expression > Creation, leaving E12 Production and E65 Creation. > > * > > Removing Rnn as the superproperty of R17 created (was created by) > [D: F28; R: F2], leaving just P94 has created (was created by) [D: > E65; R: E28] as the superproperty. > > For reference, the latest versions of the definitions of F56 and Rnn: > > > F56 Externalization Event > > Subclass of: _E7 <#_E7_Activity_>_Activity > > Superclass of: F28 Expression Creation > > _F31 <#_F31_Performance>_Performance > > Scope note: This class comprises activities that produce signs or > sensory impressions as organized and complete wholes, typically > intended to be received, in this completeness, by some audience, > either directly via their senses or via persistent media at some later > time. It comprises in particular novel externalizations of thought ? > art in all forms ? including rendering existing expressions such as > musical scores, theatre plays, scripts or texts, in a particular > manner, including through the performing arts, writing or other > methods of externalization. > > Examples: > > * > > the creation of the original manuscript score ?Uwertura tragicna? > by Andrej Panufnik in Warsaw (F28) > > * > > the reconstruction from memory of the manuscript score ?Uwertura > tragicna? by Andrej Panufnik in 1945 after the original score was > destroyed during the war (F28) > > * > > performing the ballet entitled ?Rite of Spring?, as choreographed > by Pina Bausch, in Avignon, at the Popes? Palace, on July 7, 1995 > [individual performance] (F31) > > * > > performing the operatic work entitled ?Dido and Aeneas?, as > directed by Edward Gordon Craig and conducted by Martin Shaw, in > London, Hampstead Conservatoire, on May 17, 18, and 19, 1900 [run > of performances] (F31) > > > Properties: Rnn3 was remembered in (is memory of): _F2 > <#_F2_Expression_1>_Expression > > > Rnn3 was remembered in (contains memory of) > > Domain: _F56_Externalization Event > > Range: _F2 <#_F2_Expression>_Expression > > Subproperty of: E1 CRM Entity. _P67 <#_P67_refers_to>_i is referred to > by: _E89 <#_E89_Propositional_Object>_Propositional Object [or may be > Out of CIDOC CRM Scope?] > > Superproperty of: F28 Expression Creation. R17 created (was created > by): _F2 <#_F2_Expression_1>_Expression > > Quantification: many to many, necessary, dependent (1,n:1,n) > > Scope note: This property associates an instance of F56 > Externalization Event with the instance of F2 Expression that records > or refers to the content of that particular externalization event, in > whole or in part. This recording may be done either directly or be > transferred through tradition. The expression that records the > externalization event may or may not be an expression of the work that > was externalized in the event. > > [No approved examples] > > > > > Pat Riva > Acting University Librarian / Biblioth?caire en chef par int?rim > Concordia University / Universit? Concordia > 1455 de Maisonneuve West, LB-331 > Montr?al, Qu?bec H3G 1M8 > Canada > pat.riva at concordia.ca > > > _______________________________________________ > Crm-sig mailing list > Crm-sig at ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig -- ------------------------------------ Dr. Martin Doerr Honorary Head of the 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 Vox:+30(2810)391625 Email:martin at ics.forth.gr Web-site:http://www.ics.forth.gr/isl -------------- next part -------------- An HTML attachment was scrubbed... URL: From pat.riva at concordia.ca Thu Apr 28 07:27:00 2022 From: pat.riva at concordia.ca (Pat Riva) Date: Thu, 28 Apr 2022 04:27:00 +0000 Subject: [Crm-sig] Call for e-vote: LRMoo, F29 Recording Event and its properties Message-ID: Hello all, This is the last in the series of LRMoo e-votes relating to topics previously discussed at SIG meetings but not voted on. This discussion was held during the October 2021 SIG without a formal vote, but there seemed to be consensus. Proposal: Deprecate the class F29 Recording Event, its associated properties R20 recorded (was recorded by), and R65 recorded aspects of (has aspects recorded through). Reasoning: The properties R20 and R65 as declared in FRBRoo ver.2.4, have issues with their superproperty statements due to changes brought in with CRMbase 7.1. As defined, only the very general property P15 was influenced by (influenced) could be a candidate superproperty that remains compatible with the ranges. The ranges of these properties are very broad: R20 has range E2 Temporal Entity, and R65 has range E18 Thing. These broad concepts of capturing, particularly R65, are much broader than the scope of LRMoo. F29 Recording Event is unneeded as a class without its specific properties. It is declared as a subclass of F28 Expression Creation, but actually should be a subclass of F30 Manifestation Creation. The F30 and F28 events can operate via recording, but the broader classes can have all the relationships needed to fully characterize the events. If you agree, vote Yes. If you disagree vote No, preferably with an explanation. To refer the discussion to a future SIG meeting, vote VETO. Please vote by May 4, at which point I will summarize for the list. For reference, the currently approved definitions. F29 Recording Event Subclass of: F28 Expression Creation Scope note: This class comprises activities that intend to convey (and preserve) the features of perdurants in a recording, such as a live recording of a performance, a documentary, or other capture of a perdurant. Such activities may follow the directions of a recording plan. They may include post-production. Examples: * the making of the recording of the third alternate take of the musical work titled ?Blue Hawaii? as performed by Elvis Presley in Hollywood, California, Radio Recorders, on March 22nd, 1961 * the making of the photograph of the three Allied leaders at Yalta in February 1945 * the making of the recording of an East Australian humpback whale song in 1994 in the framework of the Oceania Project * filming Louise Bourgeois at work in the context of the shooting of the documentary entitled ?Louise Bourgeois: The Spider, the Mistress, and the Tangerine? Properties: R20 recorded (was recorded through): E2 Temporal Entity R65 recorded aspects of (had aspects recorded through): E18 Physical Thing R20 recorded (was recorded through) Domain: F29 Recording Event Range: E2 Temporal Entity Subproperty of: E7 Activity. P15 was influenced by (influenced):E5 Event. P9i forms part of: E5 Event. P9 consists of: E5 Event Quantification: many to many, necessary (1,n:0,n) Scope note: This property associates an instance of F29 Recording Event with the instance of E2 Temporal Entity which was captured. Examples: The making of the recording of the third alternate take of the musical work entitled ?Blue Hawaii? as performed by Elvis Presley in Hollywood, California, Radio Recorders, on March 22nd, 1961 (F29) recorded Elvis Presley?s performance of the musical work entitled ?Blue Hawaii? in Hollywood, California, Radio Recorders, on March 22nd, 1961 (F31). R65 recorded aspects of (had aspects recorded through) Domain: F29 Recording Event Range: E18 Physical Thing Shortcut of: F29 Recording Event. R20 recorded: E3 Condition State. P44i is condition of: E18 Physical Thing Subproperty of shortcut of: F29 Recording Event. R20 recorded: E5 Event. P12 occurred in the presence of: E18 Physical Thing Quantification: many to many (0,n:0,n) Scope note: This property associates an instance of F29 Recording Event with an instance of E18 Physical Thing some of whose features, at the time of recording, were recorded in that process. Examples: The making of the photograph of the three Allied leaders at Yalta in February 1945 (F29) recorded aspects of Stalin (E21). Filming Louise Bourgeois at work in the context of the shooting of the documentary entitled ?Louise Bourgeois: The Spider, the Mistress, and the Tangerine? (F29) recorded aspects of Louise Bourgeois (E21). Pat Riva Acting University Librarian / Biblioth?caire en chef par int?rim Concordia University / Universit? Concordia 1455 de Maisonneuve West, LB-331 Montr?al, Qu?bec H3G 1M8 Canada pat.riva at concordia.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: From pat.riva at concordia.ca Thu Apr 28 07:29:46 2022 From: pat.riva at concordia.ca (Pat Riva) Date: Thu, 28 Apr 2022 04:29:46 +0000 Subject: [Crm-sig] Call for e-vote: LRMoo, F56 Externalization Event In-Reply-To: References: Message-ID: For this e-vote that was supposed to close on April 27, I only have 4 votes (between votes directly received and on the list). It would be better to have a few more votes, and so I am extending the voting period to May 4. We very much appreciate everyone taking the time to vote on so many e-votes! We're getting so very close to a stable draft of LRMoo. Thanks, Pat Pat Riva Acting University Librarian / Biblioth?caire en chef par int?rim Concordia University / Universit? Concordia 1455 de Maisonneuve West, LB-331 Montr?al, Qu?bec H3G 1M8 Canada pat.riva at concordia.ca ________________________________ From: Crm-sig on behalf of Pat Riva via Crm-sig Sent: April 20, 2022 11:57 PM To: CRM-SIG Subject: [Crm-sig] Call for e-vote: LRMoo, F56 Externalization Event Hello all, Continuing the series of LRMoo e-votes relating to topics previously discussed at SIG meetings but not voted on. This discussion was held during the October 2021 SIG without a formal vote, but there seemed to be consensus. Proposal: Deprecate the class F56 Externalization Event, and its property Rnn was remembered in (is memory of). Remark on status: F56 was approved, but only in LRMoo and so has never been implemented. Rnn was never fully approved or numbered. Its superproperty is not determined and none of the examples previously proposed have been approved. Thus, it may not be quite correct to say these are being deprecated, rather they are being withdrawn? Reasoning: F56 was conceived as a node to bring together the classes F28 Expression Creation and F31 Performance and express their generalization. This is not essential as, eventually, both classes do meet at E7 Activity. The only property of F56 is the (incomplete) Rnn which only expresses a generalization of the R17 property linking an expression creation to an expression. If you agree, vote Yes. If you disagree vote No, preferably with an explanation. To refer the discussion to a future SIG meeting, vote VETO. Please vote by April 27, at which point I will summarize for the list. If yes, these editorial modifications also follow: * Changing superclass of F31 Performance back to E7 Activity (the superclass as it was in FRBRoo v.2.4). * Removing F56 from the list of superclasses of F28 Expression Creation, leaving E12 Production and E65 Creation. * Removing Rnn as the superproperty of R17 created (was created by) [D: F28; R: F2], leaving just P94 has created (was created by) [D: E65; R: E28] as the superproperty. For reference, the latest versions of the definitions of F56 and Rnn: F56 Externalization Event Subclass of: E7 Activity Superclass of: F28 Expression Creation F31 Performance Scope note: This class comprises activities that produce signs or sensory impressions as organized and complete wholes, typically intended to be received, in this completeness, by some audience, either directly via their senses or via persistent media at some later time. It comprises in particular novel externalizations of thought ? art in all forms ? including rendering existing expressions such as musical scores, theatre plays, scripts or texts, in a particular manner, including through the performing arts, writing or other methods of externalization. Examples: * the creation of the original manuscript score ?Uwertura tragicna? by Andrej Panufnik in Warsaw (F28) * the reconstruction from memory of the manuscript score ?Uwertura tragicna? by Andrej Panufnik in 1945 after the original score was destroyed during the war (F28) * performing the ballet entitled ?Rite of Spring?, as choreographed by Pina Bausch, in Avignon, at the Popes? Palace, on July 7, 1995 [individual performance] (F31) * performing the operatic work entitled ?Dido and Aeneas?, as directed by Edward Gordon Craig and conducted by Martin Shaw, in London, Hampstead Conservatoire, on May 17, 18, and 19, 1900 [run of performances] (F31) Properties: Rnn3 was remembered in (is memory of): F2 Expression Rnn3 was remembered in (contains memory of) Domain: F56 Externalization Event Range: F2 Expression Subproperty of: E1 CRM Entity. P67i is referred to by: E89 Propositional Object [or may be Out of CIDOC CRM Scope?] Superproperty of: F28 Expression Creation. R17 created (was created by): F2 Expression Quantification: many to many, necessary, dependent (1,n:1,n) Scope note: This property associates an instance of F56 Externalization Event with the instance of F2 Expression that records or refers to the content of that particular externalization event, in whole or in part. This recording may be done either directly or be transferred through tradition. The expression that records the externalization event may or may not be an expression of the work that was externalized in the event. [No approved examples] Pat Riva Acting University Librarian / Biblioth?caire en chef par int?rim Concordia University / Universit? Concordia 1455 de Maisonneuve West, LB-331 Montr?al, Qu?bec H3G 1M8 Canada pat.riva at concordia.ca -------------- next part -------------- An HTML attachment was scrubbed... URL: