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 >
_______________________________________________ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
