Re: [Crm-sig] NEW ISSUE: Statements about Statements.
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 < [email protected]> 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" > À "BERETTA Francesco" > Cc "E. Tsoulouha" ; "[email protected]" < > [email protected]> > 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 < > [email protected]> 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 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 < >>> [email protected]> 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. >>>> Performan
Re: [Crm-sig] NEW ISSUE: Statements about Statements.
Dear All, I have noted all your declarations of interest in this discussion! Next week, I'll set up an initial google document open to all members of this mailing list. I'll keep the discussions to those interested until we have a basic agreement about the document. See also: https://enterprise-knowledge.com/rdf-what-is-it-and-why-do-i-need-it/ best, Martin -- 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: [email protected] Web-site: http://www.ics.forth.gr/isl ___ Crm-sig mailing list [email protected] http://lists.ics.forth.gr/mailman/listinfo/crm-sig
Re: [Crm-sig] NEW ISSUE: Statements about Statements.
Dear Martin, I am not a formal member of SIG but I would like to follow this discussion. So, if there is a separate list please let me know. You might find useful a recently published article entitled “Representing provenance and track changes of cultural heritage metadata in RDF: a survey of existing approaches” https://arxiv.org/abs/2305.08477 Thanks Manolis On Mon, 15 May 2023 at 20:19, Martin Doerr via Crm-sig wrote: > 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 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 < >> [email protected]> 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 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
Re: [Crm-sig] NEW ISSUE: Statements about Statements.
Dear Martin, I would like to follow this discussion too, please. Thanks. Best regards -- Béatrice Markhoff Associate Professor in Computer Science on secondment in UMR 7324 CITERES LAT Faculté des Sciences et Techniques Université de Tours, Blois, France Correspondante égalité site de Blois Le 16/05/2023 à 08:47, George Bruseker via Crm-sig a écrit : I would like to see what is discussed. G On Tue, May 16, 2023 at 8:41 AM Francesco Beretta via Crm-sig 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 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 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 types and extensions we used. The Dig model was used to trace provenance of annotated area through
Re: [Crm-sig] NEW ISSUE: Statements about Statements.
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" mailto:[email protected]>> À "BERETTA Francesco" mailto:[email protected]>> Cc "E. Tsoulouha" mailto:[email protected]>>; "[email protected]<mailto:[email protected]>" mailto:[email protected]>> 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 mailto:[email protected]>> 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 mailto:[email protected]>> 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 mailto:[email protected]>> 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 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 wo
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 < [email protected]> 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 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 < >> [email protected]> 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 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
Re: [Crm-sig] NEW ISSUE: Statements about Statements.
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 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 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 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
Re: [Crm-sig] NEW ISSUE: Statements about Statements.
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 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 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 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",
Re: [Crm-sig] NEW ISSUE: Statements about Statements.
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 < [email protected]> wrote: > Hi Martin, > > I would like to be involved. > > Thanks, > > Dominic > > > > On Sun, 14 May 2023 at 19:34, Martin Doerr 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 < >> [email protected]> 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 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 ha
Re: [Crm-sig] NEW ISSUE: Statements about Statements.
Hi Martin, I would like to be involved. Thanks, Dominic On Sun, 14 May 2023 at 19:34, Martin Doerr 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 < > [email protected]> 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 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 b
