Dear Martin, I'm also interested in participating in this group.
Best regards, Pavlos On Sun, May 14, 2023 at 10:55 PM Dominic Oldman via Crm-sig < crm-sig@ics.forth.gr> 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 >> >> _______________________________________________ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > -- Pavlos Fafalios Postdoctoral researcher Centre for Cultural Informatics & Information Systems Laboratory Institute of Computer Science - FORTH Visiting Lecturer Department of Management Science & Technology Hellenic Mediterranean University Web: http://users.ics.forth.gr/~fafalios/ Email: fafal...@ics.forth.gr Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece Tel: +30-2810-391619
_______________________________________________ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
