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 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 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 < 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 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 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
