Hello, I also would like to see what is discussed.
Many thanks. On Tue, May 16, 2023 at 9:19 AM BOTTINI Thomas via Crm-sig < crm-sig@ics.forth.gr> wrote: > Hello, > > I also would like to see what is discussed. > > Many thanks. > > --- > > Thomas Bottini > > IReMus — Institut de Recherche en Musicologie UMR 8223 > > > ------ Message d'origine ------ > De "George Bruseker via Crm-sig" <crm-sig@ics.forth.gr> > À "BERETTA Francesco" <francesco.bere...@ish-lyon.cnrs.fr> > Cc "E. Tsoulouha" <tsoulo...@ics.forth.gr>; "crm-sig@ics.forth.gr" < > crm-sig@ics.forth.gr> > Date 16/05/2023 08:47:06 > Objet Re: [Crm-sig] NEW ISSUE: Statements about Statements. > > I would like to see what is discussed. G > > On Tue, May 16, 2023 at 8:41 AM Francesco Beretta via Crm-sig < > crm-sig@ics.forth.gr> wrote: > >> Dear Martin, >> >> I'm also interested in participating in this work. >> >> Best wishes >> >> Francesco >> >> Le 15.05.23 à 19:14, Martin Doerr via Crm-sig a écrit : >> >> You are all welcome! >> >> I'll send you soon an outline of what I have in mind. >> >> All the best, >> >> Martin >> >> n 5/14/2023 10:55 PM, Dominic Oldman wrote: >> >> Hi Martin, >> >> I would like to be involved. >> >> Thanks, >> >> Dominic >> >> >> >> On Sun, 14 May 2023 at 19:34, Martin Doerr <mar...@ics.forth.gr> wrote: >> >>> Dear Dominic, all, >>> >>> Yes, I will always defend that modeling is technology independent, >>> limited however to the degree that science and technology should at least >>> provide the prospect of implementation in the near future, and some viable >>> approximations immediately. We definitely started the CRM before the >>> technology was generally available but expected. The primary criterion is >>> that the model reflects our insight about the scientific discourse we >>> target at. As such, I see the model-level discussion to be between >>> reasoning about "proposition sets" versus a "single binary proposition". >>> The technical discussion should be about best and most effective >>> approximations, regardless popular or not. The effectiveness will depend on >>> use cases and platform requirements. >>> >>> Please let us know, who is interested in participating in a narrower >>> subgroup for creating a document analyzing the alternatives. >>> >>> Best, >>> >>> Martin >>> >>> On 5/11/2023 8:01 PM, Dominic Oldman wrote: >>> >>> Hi >>> >>> Just a quick question on this. We develop the model independently of >>> technology. I can see that this discussion is getting technical. I >>> currently implement propositions sets using RDF named graphs because we can >>> and it works but it is not stipulated. Rob suggests that there are tech >>> upgrades that might suit this issue better. However, isn't it the case that >>> we need to be able to implement in different ways (I don't currently know >>> much about RDF*) depending on the systems we have? How is RDF* implemented? >>> - is it backwardly compatible with what we are all using? Do we give more >>> modelling credence to things that everyone uses? etc., etc. But aren't >>> these questions the reason why we are technology independent? Given this, >>> my question is, - have we got to a stage when the modelling now depends on >>> a particular technology? Can someone provide some clarification on this? >>> Which solution is tech independent? Are they all independent of this tech >>> discussion? One is at least. >>> >>> D >>> >>> On Thu, 11 May 2023 at 16:18, Martin Doerr via Crm-sig < >>> crm-sig@ics.forth.gr> wrote: >>> >>>> Dear Robert, >>>> >>>> We have just created the new issue to discuss this in detail. We should >>>> prepare a detailed analysis, citing all pros and cons. May be we continue >>>> this discussion better in a subgroup? >>>> >>>> Named Graphs are not a very specific technology, if we take the fact >>>> that all current triple stores are actually implemented as quad stores, >>>> regardless whether they call the construct "Named Graph" or "context". We >>>> have used and implemented this feature, and it is very performant. It runs >>>> on BlazeGraph as well. I think their is not a simple answer to that. >>>> Performance can become a major issue, when you have really a lot of data. >>>> >>>> For the attribution of artists and "style of" vs "school of" etc. of >>>> the collection management system of the British Museum, the ResearchSpace >>>> Project had created a set of subproperties of P14 carried out by, which >>>> could be used as input for a roles vocabulary. >>>> >>>> I did not propose to use Dig as is, but to consider the construct. The >>>> W3C annotation model is very interesting. We would need a connection to the >>>> Creation Event of making an annotation, and whose opinion it is, in order >>>> to make it CRM compatible. Why not allowing a Named Graph as target? We >>>> should compare the segment construct of the W3C annotation model with the >>>> METS <area> types and extensions we used. The Dig model was used to trace >>>> provenance of annotated area through transformations of digital objects. >>>> That was very important for exchanging research insights on 3D models. To >>>> be discussed! >>>> >>>> We can extend E13 to Proposition Sets, which would be very important >>>> to describe consistently CRMinf and generalized observations. That would >>>> then be most effectively implementd via Named Graphs. >>>> >>>> Opinions? >>>> >>>> Best, >>>> >>>> Martin >>>> >>>> On 5/11/2023 3:41 PM, Robert Sanderson wrote: >>>> >>>> >>>> If the intent is that the assertion is in the discourse, and not a >>>> syntactic workaround for .1 properties that would be unnecessary if we had >>>> RDF* or property graphs, then I would say E13 is exactly the right approach >>>> to use. In comparison, I consider the PC classes to be just that - a >>>> syntactic work around needed in RDF and not part of the discourse. In >>>> LInked Art, in a discussion around uncertain attribution of artists and >>>> "style of" vs "school of", we posited the need for a property on E13 for >>>> this scenario. (Also the need for .1 on P11 for the same reason as we have >>>> it on P14) >>>> >>>> I would say that Dig's annotation is *not* the correct approach for >>>> several reasons: >>>> * Named Graphs are a very specific technology that have never seen >>>> significant uptake and are likely (IMO) to decrease in usage once RDF* is >>>> formalized. >>>> * Dig needs to be updated, and Annotation is (I would hope) likely to >>>> go away ... because ... >>>> * ... it could just use the Web Annotation Data Model: >>>> https://www.w3.org/TR/annotation-model/ >>>> >>>> (And reification has all the problems discussed in this thread already) >>>> >>>> Rob >>>> >>>> >>>> On Thu, May 11, 2023 at 7:17 AM George Bruseker via Crm-sig < >>>> crm-sig@ics.forth.gr> wrote: >>>> >>>>> Dear Martin, >>>>> >>>>> I agree that E13 is a poor man's solution to a complicated problem. >>>>> But it is for some, the solution available. Other solutions like Inf for >>>>> documenting historical argumentation and using named graphs is great as a >>>>> possibility. Using prov o to represent the meta discursive level of the >>>>> provenance of the dataset as such great. But my immediate interest was >>>>> simple the humble ability of E13 to be able to point to all statements >>>>> that >>>>> can be made with precisely one link in CRM. I'll keep watching the space! >>>>> >>>>> Cheers, >>>>> >>>>> G >>>>> >>>>> On Thu, May 11, 2023 at 1:25 PM Martin Doerr <mar...@ics.forth.gr> >>>>> wrote: >>>>> >>>>>> Dear George, >>>>>> >>>>>> I agree with you below about the historical aspects. The annotation >>>>>> model has the same historical aspect, but is not limited to a single >>>>>> link. >>>>>> >>>>>> Let us discuss!😁 >>>>>> >>>>>> Best, >>>>>> >>>>>> Martin >>>>>> >>>>>> On 5/11/2023 12:41 PM, George Bruseker wrote: >>>>>> >>>>>> Dear Francesco, Martin, >>>>>> >>>>>> Again for the record since I seem to be being read at cross purposes, >>>>>> when I mention the word 'provenance' I do not mean it in the sense of >>>>>> dataset provenance (to which prov o would apply). I mean that in the >>>>>> world >>>>>> to be described (the real world of tables charis cats dogs scholars ideas >>>>>> etc.) there are real world events in which people attribute things to >>>>>> things (see my previous email). This is content of the world to be >>>>>> represented in the semantic graph (not a metagraph about the graph). This >>>>>> is describable and is described in CIDOC CRM using E13 and its friends. >>>>>> If >>>>>> you want to say that there was a historical situation that someone in >>>>>> your >>>>>> department said (likely in the information system) that some attribute >>>>>> related two things you can do this with E13 (or I have >>>>>> completely misunderstood the CIDOC CRM). This happens all the time in art >>>>>> history. One particular often arising case is an argument about who >>>>>> played >>>>>> what role in some object. Was Davinci the painter or was it Simon? This >>>>>> is >>>>>> just a hum drum case of needing to apply CIDOC CRM to real cases. Since >>>>>> E13 >>>>>> is a mechanism for so doing on all other statements, it would be a >>>>>> logical >>>>>> continuation that it could be used also on .1 statements. But for >>>>>> technical >>>>>> reasons it cannot, that is why I suggested a mild technical solution that >>>>>> makes the technical extension logically coherent. It is in this sense >>>>>> that >>>>>> I mean provenance and not in the metasense of the provenance of the data >>>>>> qua data, also an exciting but other issue to my mind. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> George >>>>>> >>>>>> On Thu, May 11, 2023 at 12:27 PM Martin Doerr via Crm-sig < >>>>>> crm-sig@ics.forth.gr> wrote: >>>>>> >>>>>>> Dear Francesco, >>>>>>> >>>>>>> This is an excellent paper. >>>>>>> >>>>>>> I cite: "However, reification has no formal semantics, and leads to >>>>>>> a high increase in the number of triples, hence, it does not scale >>>>>>> well. " >>>>>>> >>>>>>> I agree with your proposals. Prov-O mapping is a must for CRM-SIG. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> On 5/10/2023 11:55 PM, Francesco Beretta via Crm-sig wrote: >>>>>>> >>>>>>> Dear Martin, George, All, >>>>>>> >>>>>>> I would not dare to suggest some solution of this complex issue but >>>>>>> let me hint to a couple of useful papers (among many others): >>>>>>> >>>>>>> Sikos, Leslie F., and Dean Philp, ‘Provenance-Aware Knowledge >>>>>>> Representation: A Survey of Data Models and Contextualized Knowledge >>>>>>> Graphs’, *Data Science and Engineering*, 5.3 (2020), 293–316 < >>>>>>> https://doi.org/10.1007/s41019-020-00118-0> >>>>>>> >>>>>>> Hernández, Daniel, Aidan Hogan, and Markus Krötzsch, ‘Reifying RDF: >>>>>>> What Works Well With Wikidata?’, in *Proceedings of the 11th >>>>>>> International Workshop on Scalable Semantic Web Knowledge Base Systems >>>>>>> Co-Located with 14th International Semantic Web Conference (ISWC 2015), >>>>>>> Bethlehem, PA, USA, October 11, 2015.*, 2015, pp. 32–47 < >>>>>>> http://ceur-ws.org/Vol-1457/SSWS2015_paper3.pdf> >>>>>>> >>>>>>> >>>>>>> Once again, I would like to suggest carefully distinguishing between >>>>>>> the CRM domain of discourse, in which the E13 class is conceptualized, >>>>>>> and >>>>>>> the issue of stating the provenance of the information modelled in the >>>>>>> discourse domain, including instances of class E13 as part of the >>>>>>> modelled >>>>>>> domain. >>>>>>> >>>>>>> For this last task (or domain of discourse), it would seems >>>>>>> reasonable and in line with best practices to use the PROV model and the >>>>>>> corresponding PROV-O ontology, a W3C recommendation. Or providing a >>>>>>> specific extension of the CRM, compatible and aligned with the PROV >>>>>>> model. >>>>>>> But using PROV-O seems a good choice in order to facilitate >>>>>>> interoperability. >>>>>>> >>>>>>> There remains the more fundamental question of whether the current >>>>>>> debate about RDF implementation is not in fact indicative of a more >>>>>>> fundamental problem related to properties of properties and the implicit >>>>>>> and richer information they contain, which cannot be adequately >>>>>>> expressed >>>>>>> in RDF without conceptualising them in terms of actual classes. Aren't >>>>>>> these rather hybrid P(roperty)C(lasses), especially if they should be >>>>>>> declared as subclasses of E1, to be considered as *de facto* >>>>>>> classes and not just properties? Because if they are just statements, >>>>>>> then >>>>>>> adopting one or the other form of existing RDF reifications practices >>>>>>> seems >>>>>>> to be the good way to go. >>>>>>> >>>>>>> Best >>>>>>> >>>>>>> Francesco >>>>>>> >>>>>>> >>>>>>> Le 10.05.23 à 18:48, Martin Doerr via Crm-sig a écrit : >>>>>>> >>>>>>> Dear All, >>>>>>> >>>>>>> I suggest to resolve the issue of referring to the provenance of .1 >>>>>>> properties more specifically: >>>>>>> >>>>>>> Solution a: Add properties to E13 to specify a .1 property. This may >>>>>>> be more effective than the double indirection via PC class instance and >>>>>>> 4 >>>>>>> links of the E13 construct. >>>>>>> >>>>>>> Solution b: Use RDF reification for this specific problem via the PC >>>>>>> class. >>>>>>> >>>>>>> We need to examine in both cases the inferences we want to maintain >>>>>>> about the base property and its domain and range, and what the relevant >>>>>>> query construct is. >>>>>>> >>>>>>> Personally, I prefer solution c: Use the annotation model of CRM >>>>>>> Dig, which goes via Named Graphs. This is much more performant and >>>>>>> logically clearer, because Named Graphs are implemented as direct >>>>>>> references to property identifier, and maintain a reference count for >>>>>>> each >>>>>>> one. This is an important logic in its own right. Inferences about the >>>>>>> .properties would work in out ouf of a Named Graph, whereas the >>>>>>> reification >>>>>>> may need additional rules. >>>>>>> >>>>>>> The query languages of Quad stores support them explicitly. >>>>>>> >>>>>>> The latest version of 3M supports Named Graph definitions. This >>>>>>> feature should be tested. >>>>>>> >>>>>>> I would rather discourage E13 in the long term as a means to denote >>>>>>> provenance generally and recommend a uniform use of Named Graphs. I am >>>>>>> aware that not all RDF encodings support the feature. I that case we >>>>>>> could >>>>>>> resort to reification. >>>>>>> >>>>>>> Opinions? >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> On 5/9/2023 10:37 PM, Francesco Beretta via Crm-sig wrote: >>>>>>> >>>>>>> Dear Christian-Emil, All, >>>>>>> >>>>>>> For the reasons I detailed in my other email, I totally agree with >>>>>>> your point of view and would like to raise all possible caveats to this >>>>>>> kind of mixing up quick and dirty implementation solutions and >>>>>>> consistent >>>>>>> conceptual modelling. >>>>>>> >>>>>>> If we need more classes, even on a provisional and experimental >>>>>>> perspective, I would strongly suggest to produce them and document them >>>>>>> as >>>>>>> such, with stable URIs, and then refine progressively the ontology and >>>>>>> integrate it into the CRM family. Of course, a nice place to do this is >>>>>>> ontome.net 😉 >>>>>>> >>>>>>> Best >>>>>>> >>>>>>> Francesco >>>>>>> >>>>>>> Le 08.05.23 à 17:36, Christian-Emil Smith Ore via Crm-sig a écrit : >>>>>>> >>>>>>> Also: RDF(S) is an implementation technology. We can assume that >>>>>>> there exists a implmentation function from the CRM-FOL to RDF(S), but >>>>>>> this >>>>>>> may not be a 1-1 function. Strange constructs like the PC0(?) may not >>>>>>> have >>>>>>> counterparts in CRM-FOL. Changing the ontology on the bases of >>>>>>> special tricks used in the implementation may not always be a good idea, >>>>>>> but may inspire us to make well thought out and consistent changes in >>>>>>> the >>>>>>> ontology. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Crm-sig mailing list >>>>>>> Crm-sig@ics.forth.gr >>>>>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Crm-sig mailing >>>>>>> listCrm-sig@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: mar...@ics.forth.gr >>>>>>> Web-site: http://www.ics.forth.gr/isl >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Crm-sig mailing list >>>>>>> Crm-sig@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: mar...@ics.forth.gr >>>>>> Web-site: http://www.ics.forth.gr/isl >>>>>> >>>>>> _______________________________________________ >>>>> Crm-sig mailing list >>>>> Crm-sig@ics.forth.gr >>>>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >>>>> >>>> >>>> >>>> -- >>>> Rob Sanderson >>>> Senior Director for Digital Cultural Heritage >>>> Yale University >>>> >>>> >>>> >>>> -- >>>> ------------------------------------ >>>> 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: mar...@ics.forth.gr >>>> Web-site: http://www.ics.forth.gr/isl >>>> >>>> _______________________________________________ >>>> Crm-sig mailing list >>>> Crm-sig@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: mar...@ics.forth.gr >>> Web-site: http://www.ics.forth.gr/isl >>> >>> >> >> -- >> ------------------------------------ >> 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: mar...@ics.forth.gr >> Web-site: http://www.ics.forth.gr/isl >> >> >> _______________________________________________ >> Crm-sig mailing >> listCrm-sig@ics.forth.grhttp://lists.ics.forth.gr/mailman/listinfo/crm-sig >> >> >> _______________________________________________ >> Crm-sig mailing list >> Crm-sig@ics.forth.gr >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> > _______________________________________________ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > -- Anaïs Guillem REPERAGE Project, Laboratoire de Recherche des Monuments Historiques GT Écosystème Numérique, Chantier scientifique Notre-Dame de Paris +33 630005089
_______________________________________________ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
