Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Dominic Oldman via Crm-sig]

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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Martin Doerr via Crm-sig]

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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Robert Sanderson via Crm-sig]

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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Martin Doerr via Crm-sig]

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

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 


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 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

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 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Martin Doerr via Crm-sig]

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 



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 




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 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Francesco Beretta via Crm-sig]

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 



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 




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 list

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Martin Doerr via Crm-sig]

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



--

 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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

Hi everyone,

To be clear I at no point suggested changing the ontology specification. I
proposed making the rdfs for pc classes consistent logically. It presently
isn't. If this is too big a leap for some it is not a problem I will just
implement it locally because I can't have unprovenanced statements.

Cheers

George

On Tue, 9 May 2023, 10:39 pm Francesco Beretta via Crm-sig, <
crm-sig@ics.forth.gr> 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 list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Francesco Beretta via Crm-sig]

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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Martin Doerr via Crm-sig]

Got it!

So, the specific problem is to enable E13 to point to .1 properties.  
That appears to be a problem of E13, and possibly of 3M, isn't it? Could 
be solved by a more specific construct.


Best,

Martin

On 5/8/2023 9:14 PM, George Bruseker wrote:

Hi Martin,

The problem to solve is, how do you find who said that .1 anything?

This is often where the true scholarly interest is. It is a matter for 
aliens and economists to count how many people were involved in 
carrying out actions in a knowledge graph (the pure empirical 
picture). Actually, we want to do who did what in what capacity. We 
want to know what referenced what in what capacity. So the information 
represented in the .1 isn't a fun additional node, it is the vital 
piece of information that makes the graph interesting in the first place.




For me it is a big problem if there are statements in the CRM
that can be made (Bob was the builder) but can't be discussed.
The abox statement Bob was the builder is definitely in the
domain of discourse and for that reason should necessarily as a
matter of principle be referenceable.

I do not get the point. All statements, property instances, are
referenceable, by reification, Named Graphs, A13. Bob being in the
role of builder for that Activity can be formalized as
specialication of the P14 carried out by. What problem do you try
to solve?


The point is that they are not. Load up 3M and try to do an E13 
reification on a PC property class. You cannot. Because E13 points to 
an instance of E1 and PCs are not (by accident I suspect, this has 
never been formally discussed to my knowledge) not declared as a 
subclass of E1.


So when the scholarly questions are, what role did X play in Y, what 
manner did Z reference P, and who said that, then the thing that is of 
interest to be questioned / contested / understood is the property on 
the property which cannot be referenced. So the problem is to make CRM 
useful for scholarly documentation and argumentation!




Otherwise, CRMbase cannot state the provenance for a piece of
knowledge like Da Vinci had the role of painter of Mona Lisa. It
becomes impossible. The abox information is in the PC14 instance.

Why not? Provenance of knowledge is an epistemic layer on top of
any KB. We have written in the introduction detailed explanations
about that. Reification


It cannot be used on a PC class because of the issue that is the issue 
that I raised in this issue (it is not a subclass of E1).




Yes we can use the partitioning pattern which is fine, but it
remains a question of technically what to do about PC classes and
it seems only half baked if they aren't instances of E1. They fit
the definition of instances of E1, "This class comprises all
things in the universe of discourse of the CIDOC Conceptual
Reference Model." Being in the role of the painter of Mona Lisa
is, for me, a thing in the universe of discourse of the CIDOC
Conceptual Reference Model.

Well, then we have to refine the term "thing". Clearly, E1 is used
exclusively for individual entities. We did not model so far a
"CRM relation", in order to avoid that people instantiate an
unqualified relation.


We already model properties also as classes not only in PC but quite 
explicitly in P177 where we expected instances of E55 to be properties...




Logically, I do not get the point why making PC classes instances
of E1 does solve a problem, which reification, Named Graphs and
E13 already do?  I mean, should we make an example? Could you be
more specific why the latter 3 mechanisms do not work for any CRM
property and .1 property?


I did give an example! I drew a picture to help out. Here it is in 
draw.io :


https://drive.google.com/file/d/1Qat9TCxEBxCzylEdKkwjdnpHF3HCiiM-/view?usp=sharing

It is on two tabs. Tab one shows how we can say things about the 
relation of an actor to an event as being responsible. Tab two shows 
how we can say things about the role of an actor in an event. You 
cannot do a reference to the PC class, hence you cannot talk about it. 
(or put down the reference that grounds it or do any other scholarly 
activity related to it... although the language otherwise lets use 
sort of make a statement regarding role).


Cheers,

George


Best,

Martin


The main thing is this is a technical extension to a technical
extension to make things work and isn't a real ontological
question to my mind.

If we wanted to do the ontological discussions we would have to
open up the modelling box of worms, which is definitely another
issue. I, for example, would like to be able to talk about the
timespan of the property of something being part of something...
but that's a broader issue :)

G

On Mon, May 8, 2023 at 5:21 PM Robert Sanderson via Crm-sig
 wrote:


Perhaps for 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

Hi Martin,

The problem to solve is, how do you find who said that .1 anything?

This is often where the true scholarly interest is. It is a matter for
aliens and economists to count how many people were involved in carrying
out actions in a knowledge graph (the pure empirical picture). Actually, we
want to do who did what in what capacity. We want to know what referenced
what in what capacity. So the information represented in the .1 isn't a fun
additional node, it is the vital piece of information that makes the graph
interesting in the first place.


> For me it is a big problem if there are statements in the CRM that can be
> made (Bob was the builder) but can't be discussed. The abox statement Bob
> was the builder is definitely in the domain of discourse and for that
> reason should necessarily as a matter of principle be referenceable.
>
> I do not get the point. All statements, property instances, are
> referenceable, by reification, Named Graphs, A13. Bob being in the role of
> builder for that Activity can be formalized as specialication of the P14
> carried out by. What problem do you try to solve?
>

The point is that they are not. Load up 3M and try to do an E13 reification
on a PC property class. You cannot. Because E13 points to an instance of E1
and PCs are not (by accident I suspect, this has never been formally
discussed to my knowledge) not declared as a subclass of E1.

So when the scholarly questions are, what role did X play in Y, what manner
did Z reference P, and who said that, then the thing that is of interest to
be questioned / contested / understood is the property on the property
which cannot be referenced. So the problem is to make CRM useful for
scholarly documentation and argumentation!


>
> Otherwise, CRMbase cannot state the provenance for a piece of knowledge
> like Da Vinci had the role of painter of Mona Lisa. It becomes impossible.
> The abox information is in the PC14 instance.
>
> Why not? Provenance of knowledge is an epistemic layer on top of any KB.
> We have written in the introduction detailed explanations about that.
> Reification
>

It cannot be used on a PC class because of the issue that is the issue that
I raised in this issue (it is not a subclass of E1).

>
> Yes we can use the partitioning pattern which is fine, but it remains a
> question of technically what to do about PC classes and it seems only half
> baked if they aren't instances of E1. They fit the definition of instances
> of E1, "This class comprises all things in the universe of discourse of
> the CIDOC Conceptual Reference Model." Being in the role of the painter of
> Mona Lisa is, for me, a thing in the universe of discourse of the CIDOC
> Conceptual Reference Model.
>
> Well, then we have to refine the term "thing". Clearly, E1 is used
> exclusively for individual entities. We did not model so far a "CRM
> relation", in order to avoid that people instantiate an unqualified
> relation.
>

We already model properties also as classes not only in PC but quite
explicitly in P177 where we expected instances of E55 to be properties...



>
>
> Logically, I do not get the point why making PC classes instances of E1
> does solve a problem, which reification, Named Graphs and E13 already do?
> I mean, should we make an example? Could you be more specific why the
> latter 3 mechanisms do not work for any CRM property and .1 property?
>

I did give an example! I drew a picture to help out. Here it is in draw.io:

https://drive.google.com/file/d/1Qat9TCxEBxCzylEdKkwjdnpHF3HCiiM-/view?usp=sharing

It is on two tabs. Tab one shows how we can say things about the relation
of an actor to an event as being responsible. Tab two shows how we can say
things about the role of an actor in an event. You cannot do a reference to
the PC class, hence you cannot talk about it. (or put down the reference
that grounds it or do any other scholarly activity related to it...
although the language otherwise lets use sort of make a statement regarding
role).

Cheers,

George


>
> Best,
>
> Martin
>
>
> The main thing is this is a technical extension to a technical extension
> to make things work and isn't a real ontological question to my mind.
>
> If we wanted to do the ontological discussions we would have to open up
> the modelling box of worms, which is definitely another issue. I, for
> example, would like to be able to talk about the timespan of the property
> of something being part of something... but that's a broader issue :)
>
> G
>
> On Mon, May 8, 2023 at 5:21 PM Robert Sanderson via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>>
>> Perhaps for the first time, I agree with Martin and not George!
>>
>> The PC classes are part of the ontological layer -- we don't say that
>> classes or properties are descendants of E1. Or PC classes are T box
>> (terminology) and not A box (assertions using that terminology).
>> (See - https://en.wikipedia.org/wiki/Abox)
>>
>> I can see, however, that it would be useful to be 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Martin Doerr via Crm-sig]

Dear Christian-Emil,

On 5/8/2023 6:36 PM, Christian-Emil Smith Ore via Crm-sig wrote:


Hi all,

The E13 Attribute assignment construct does not create any formal 
connection between an instance of E13 and the  instance of the 
property  it documents. We have the property


P177 assigned property of type (is type of property assigned): E55 
Type.  It is no formal connection between this type and the property 
in question, however.



As far as I can se (which may be not very far) the FOL interpretation 
of CRM is, well, first order and we cannot quantify over predicates. 
In a second order logic this will be possible. Such a logic is 
undecidable, but may be part of it  it can be implemented by some 
constructs.


Yes, and the formalization of Named Graphs is still missing, because 
theoreticians try to solve simultaneously Named Graphs for models 
particulars and for models of universals. I wonder if even SOL has the 
epistemic semantics of "who says that. In the meanwhile, Quad stores 
practically implement the necessary semantics of Named Graphs for 
particulars.


I would like to repeat that SOL is in general undecidable, but there 
exist quite well-defined decidable subsets. Nevertheless, the idea that 
SOL is always underdecidable has been used as killer statement for a lot 
of important developments in ontology engineering. To my understanding, 
we have no need for undecidable parts of SOL. Nicola Guarino uses SOL in 
his papers.



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.







See (at least some of you) soon,

Christian-Emil




*From:* Crm-sig  on behalf of George 
Bruseker via Crm-sig 

*Sent:* 08 May 2023 16:34
*To:* Robert Sanderson
*Cc:* crm-sig@ics.forth.gr
*Subject:* Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc
Hi Rob and Martin,

But the point is not to make assertions about the property class 
itself but the instance of the property class.


The instance of PC14 says Bob was the creator, Bob was a faker... it 
is a regular abox assertion. And it has an identifier, necessarily.


The instances of PC classes are all already abox statements. They have 
just been modelled in an odd way where we don't account for their 
ontological substance. Being in a role is an ontological substance to 
define.


For me it is a big problem if there are statements in the CRM that can 
be made (Bob was the builder) but can't be discussed. The abox 
statement Bob was the builder is definitely in the domain of discourse 
and for that reason should necessarily as a matter of principle be 
referenceable.


Otherwise, CRMbase cannot state the provenance for a piece of 
knowledge like Da Vinci had the role of painter of Mona Lisa. It 
becomes impossible. The abox information is in the PC14 instance.


Yes we can use the partitioning pattern which is fine, but it remains 
a question of technically what to do about PC classes and it seems 
only half baked if they aren't instances of E1. They fit the 
definition of instances of E1, "This class comprises all things in the 
universe of discourse of the CIDOC Conceptual Reference Model." Being 
in the role of the painter of Mona Lisa is, for me, a thing in the 
universe of discourse of the CIDOC Conceptual Reference Model.


The main thing is this is a technical extension to a technical 
extension to make things work and isn't a real ontological question to 
my mind.


If we wanted to do the ontological discussions we would have to open 
up the modelling box of worms, which is definitely another issue. I, 
for example, would like to be able to talk about the timespan of the 
property of something being part of something... but that's a broader 
issue :)


G

On Mon, May 8, 2023 at 5:21 PM Robert Sanderson via Crm-sig 
 wrote:



Perhaps for the first time, I agree with Martin and not George!

The PC classes are part of the ontological layer -- we don't say
that classes or properties are descendants of E1. Or PC classes
are T box (terminology) and not A box (assertions using that
terminology).
(See - https://en.wikipedia.org/wiki/Abox)

I can see, however, that it would be useful to be able to refer to
assertions in CRMInf and perhaps in Activity templates ... but
then those assertions _are_ A box - the are the subject of the
discourse, not the language in which the discourse is taking
place.  We have Attribute Assignment to talk about important
activities that assert relationships or properties. And if we
don't want to go to that layer

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Martin Doerr via Crm-sig]

Hi George,

On 5/8/2023 5:34 PM, George Bruseker wrote:

Hi Rob and Martin,

But the point is not to make assertions about the property class 
itself but the instance of the property class.

of course


The instance of PC14 says Bob was the creator, Bob was a faker... it 
is a regular abox assertion. And it has an identifier, necessarily.


The instances of PC classes are all already abox statements. They have 
just been modelled in an odd way where we don't account for their 
ontological substance. Being in a role is an ontological substance to 
define.
Yes, we have discussed that in the past and in the OntoWeb project. 
There are 3 kinds of roles. This is the "incidental role". There was a 
classical paper about that. I'll search for it. Another role is the 
life-long role. A third one is the "persona" or "office" role.


The point I made is the difference between ontological substance of 
individuals versus that of relations, and the epistemic substance of 
arguing about the world from a bird's perspective. I did not question 
the substance of roles, but their nature as "entities" or "individuals" 
in the narrower sense.


For me it is a big problem if there are statements in the CRM that can 
be made (Bob was the builder) but can't be discussed. The abox 
statement Bob was the builder is definitely in the domain of discourse 
and for that reason should necessarily as a matter of principle be 
referenceable.
I do not get the point. All statements, property instances, are 
referenceable, by reification, Named Graphs, A13. Bob being in the role 
of builder for that Activity can be formalized as specialication of the 
P14 carried out by. What problem do you try to solve?


Otherwise, CRMbase cannot state the provenance for a piece of 
knowledge like Da Vinci had the role of painter of Mona Lisa. It 
becomes impossible. The abox information is in the PC14 instance.
Why not? Provenance of knowledge is an epistemic layer on top of any KB. 
We have written in the introduction detailed explanations about that. 
Reification


Yes we can use the partitioning pattern which is fine, but it remains 
a question of technically what to do about PC classes and it seems 
only half baked if they aren't instances of E1. They fit the 
definition of instances of E1, "This class comprises all things in the 
universe of discourse of the CIDOC Conceptual Reference Model." Being 
in the role of the painter of Mona Lisa is, for me, a thing in the 
universe of discourse of the CIDOC Conceptual Reference Model.
Well, then we have to refine the term "thing". Clearly, E1 is used 
exclusively for individual entities. We did not model so far a "CRM 
relation", in order to avoid that people instantiate an unqualified 
relation.


Logically, I do not get the point why making PC classes instances of E1 
does solve a problem, which reification, Named Graphs and E13 already 
do?  I mean, should we make an example? Could you be more specific why 
the latter 3 mechanisms do not work for any CRM property and .1 property?


Best,

Martin


The main thing is this is a technical extension to a technical 
extension to make things work and isn't a real ontological question to 
my mind.


If we wanted to do the ontological discussions we would have to open 
up the modelling box of worms, which is definitely another issue. I, 
for example, would like to be able to talk about the timespan of the 
property of something being part of something... but that's a broader 
issue :)


G

On Mon, May 8, 2023 at 5:21 PM Robert Sanderson via Crm-sig 
 wrote:



Perhaps for the first time, I agree with Martin and not George!

The PC classes are part of the ontological layer -- we don't say
that classes or properties are descendants of E1. Or PC classes
are T box (terminology) and not A box (assertions using that
terminology).
(See - https://en.wikipedia.org/wiki/Abox)

I can see, however, that it would be useful to be able to refer to
assertions in CRMInf and perhaps in Activity templates ... but
then those assertions _are_ A box - the are the subject of the
discourse, not the language in which the discourse is taking
place.  We have Attribute Assignment to talk about important
activities that assert relationships or properties. And if we
don't want to go to that layer of A box layer reification, then we
have the partitioning pattern -- to assert a role of a particular
individual in an activity, we can identify the part of that
activity that the person carried out and assert a role
classification on it via P2_has_type.

Rob


On Mon, May 8, 2023 at 9:44 AM Martin Doerr via Crm-sig
 wrote:

Dear All,

I don't think it is correct to make the PC classes entities.
Even though formally an RDF class could be regarded as an
entity, ontologically we distinguish entities and
relationships. The E-R paradigm makes this distinction also
formally 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Christian-Emil Smith Ore via Crm-sig]

Hi all,

The E13 Attribute assignment construct does not create any  formal connection 
between an instance of E13 and the  instance of the property  it documents. We 
have the property

P177 
assigned property of type (is type of property assigned): 
E55 Type. 
 It is no formal connection between this type and the property in question, 
however.


As far as I can se (which may be not very far) the FOL interpretation of CRM 
is, well, first order and we cannot quantify over predicates. In a second order 
logic this will be possible. Such a logic is undecidable, but may be part of it 
 it can be implemented by some constructs.


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.


See (at least some of you) soon,

Christian-Emil



From: Crm-sig  on behalf of George Bruseker via 
Crm-sig 
Sent: 08 May 2023 16:34
To: Robert Sanderson
Cc: crm-sig@ics.forth.gr
Subject: Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

Hi Rob and Martin,

But the point is not to make assertions about the property class itself but the 
instance of the property class.

The instance of PC14 says Bob was the creator, Bob was a faker... it is a 
regular abox assertion. And it has an identifier, necessarily.

The instances of PC classes are all already abox statements. They have just 
been modelled in an odd way where we don't account for their ontological 
substance. Being in a role is an ontological substance to define.

For me it is a big problem if there are statements in the CRM that can be made 
(Bob was the builder) but can't be discussed. The abox statement Bob was the 
builder is definitely in the domain of discourse and for that reason should 
necessarily as a matter of principle be referenceable.

Otherwise, CRMbase cannot state the provenance for a piece of knowledge like Da 
Vinci had the role of painter of Mona Lisa. It becomes impossible. The abox 
information is in the PC14 instance.

Yes we can use the partitioning pattern which is fine, but it remains a 
question of technically what to do about PC classes and it seems only half 
baked if they aren't instances of E1. They fit the definition of instances of 
E1, "This class comprises all things in the universe of discourse of the CIDOC 
Conceptual Reference Model." Being in the role of the painter of Mona Lisa is, 
for me, a thing in the universe of discourse of the CIDOC Conceptual Reference 
Model.

The main thing is this is a technical extension to a technical extension to 
make things work and isn't a real ontological question to my mind.

If we wanted to do the ontological discussions we would have to open up the 
modelling box of worms, which is definitely another issue. I, for example, 
would like to be able to talk about the timespan of the property of something 
being part of something... but that's a broader issue :)

G

On Mon, May 8, 2023 at 5:21 PM Robert Sanderson via Crm-sig 
mailto:crm-sig@ics.forth.gr>> wrote:

Perhaps for the first time, I agree with Martin and not George!

The PC classes are part of the ontological layer -- we don't say that classes 
or properties are descendants of E1. Or PC classes are T box (terminology) and 
not A box (assertions using that terminology).
(See - https://en.wikipedia.org/wiki/Abox)

I can see, however, that it would be useful to be able to refer to assertions 
in CRMInf and perhaps in Activity templates ... but then those assertions _are_ 
A box - the are the subject of the discourse, not the language in which the 
discourse is taking place.  We have Attribute Assignment to talk about 
important activities that assert relationships or properties. And if we don't 
want to go to that layer of A box layer reification, then we have the 
partitioning pattern -- to assert a role of a particular individual in an 
activity, we can identify the part of that activity that the person carried out 
and assert a role classification on it via P2_has_type.

Rob


On Mon, May 8, 2023 at 9:44 AM Martin Doerr via Crm-sig 
mailto:crm-sig@ics.forth.gr>> wrote:
Dear All,

I don't think it is correct to make the PC classes entities. Even though 
formally an RDF class could be regarded as an entity, ontologically we 
distinguish entities and relationships. The E-R paradigm makes this distinction 
also formally clear. We model the properties with .1 properties in FOL as n-ary 
relationships, and not as individuals.

Making the PC classes CRM Entities is inconsistent with the FOL definition, 
which is the proper formalization.
In other words, we would make a workaround for a missing feature in RDFS an 
on

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

Hi Rob and Martin,

But the point is not to make assertions about the property class itself but
the instance of the property class.

The instance of PC14 says Bob was the creator, Bob was a faker... it is a
regular abox assertion. And it has an identifier, necessarily.

The instances of PC classes are all already abox statements. They have just
been modelled in an odd way where we don't account for their ontological
substance. Being in a role is an ontological substance to define.

For me it is a big problem if there are statements in the CRM that can be
made (Bob was the builder) but can't be discussed. The abox statement Bob
was the builder is definitely in the domain of discourse and for that
reason should necessarily as a matter of principle be referenceable.

Otherwise, CRMbase cannot state the provenance for a piece of knowledge
like Da Vinci had the role of painter of Mona Lisa. It becomes impossible.
The abox information is in the PC14 instance.

Yes we can use the partitioning pattern which is fine, but it remains a
question of technically what to do about PC classes and it seems only half
baked if they aren't instances of E1. They fit the definition of instances
of E1, "This class comprises all things in the universe of discourse of the
CIDOC Conceptual Reference Model." Being in the role of the painter of Mona
Lisa is, for me, a thing in the universe of discourse of the CIDOC
Conceptual Reference Model.

The main thing is this is a technical extension to a technical extension to
make things work and isn't a real ontological question to my mind.

If we wanted to do the ontological discussions we would have to open up the
modelling box of worms, which is definitely another issue. I, for example,
would like to be able to talk about the timespan of the property of
something being part of something... but that's a broader issue :)

G

On Mon, May 8, 2023 at 5:21 PM Robert Sanderson via Crm-sig <
crm-sig@ics.forth.gr> wrote:

>
> Perhaps for the first time, I agree with Martin and not George!
>
> The PC classes are part of the ontological layer -- we don't say that
> classes or properties are descendants of E1. Or PC classes are T box
> (terminology) and not A box (assertions using that terminology).
> (See - https://en.wikipedia.org/wiki/Abox)
>
> I can see, however, that it would be useful to be able to refer to
> assertions in CRMInf and perhaps in Activity templates ... but then those
> assertions _are_ A box - the are the subject of the discourse, not the
> language in which the discourse is taking place.  We have Attribute
> Assignment to talk about important activities that assert relationships or
> properties. And if we don't want to go to that layer of A box layer
> reification, then we have the partitioning pattern -- to assert a role of a
> particular individual in an activity, we can identify the part of that
> activity that the person carried out and assert a role classification on it
> via P2_has_type.
>
> Rob
>
>
> On Mon, May 8, 2023 at 9:44 AM Martin Doerr via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> Dear All,
>>
>> I don't think it is correct to make the PC classes entities. Even though
>> formally an RDF class could be regarded as an entity, ontologically we
>> distinguish entities and relationships. The E-R paradigm makes this
>> distinction also formally clear. We model the properties with .1 properties
>> in FOL as n-ary relationships, and not as individuals.
>>
>> Making the PC classes CRM Entities is inconsistent with the FOL
>> definition, which is the proper formalization.
>> In other words, we would make a workaround for a missing feature in RDFS
>> an ontological argument. We are again in the discussion to take RDFS as the
>> definition of the CRM, and not as an implementation.
>>
>> As a first step, we could introduce an "E0 CRM Relation", which would
>> have as instances all properties and the PC classes. The ontological
>> distinction between relations and entities is fundamental to the
>> methodology of ontological analysis.
>>
>> As a second step, we can start to investigate to which degree PC classes
>> qualify as ontological individuals in their own right. If we start
>> declaring a priori all PC classes as entities, we have later to justify and
>> remove all those that are relations in the true sense.  For instance, I
>> cannot imagine the "being part of" a Physical Object for some time to
>> become an entity, because it needs a timespan.
>>
>> Best,
>>
>> Martin
>>
>> On 5/8/2023 12:54 PM, George Bruseker via Crm-sig wrote:
>>
>> Hi all,
>>
>> I would argue that the safest thing to do is to make the PCs a subclass
>> of E1 and then see where we go from there. I agree with Martin that it
>> can't be an information object (because everything would be then) but I
>> imagine we would have a debate about what each .1 actually ontologically
>> is. What is certain is that by virtue of the fact of being something said
>> in the universe of CIDOC CRM it is something 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Robert Sanderson via Crm-sig]

Perhaps for the first time, I agree with Martin and not George!

The PC classes are part of the ontological layer -- we don't say that
classes or properties are descendants of E1. Or PC classes are T box
(terminology) and not A box (assertions using that terminology).
(See - https://en.wikipedia.org/wiki/Abox)

I can see, however, that it would be useful to be able to refer to
assertions in CRMInf and perhaps in Activity templates ... but then those
assertions _are_ A box - the are the subject of the discourse, not the
language in which the discourse is taking place.  We have Attribute
Assignment to talk about important activities that assert relationships or
properties. And if we don't want to go to that layer of A box layer
reification, then we have the partitioning pattern -- to assert a role of a
particular individual in an activity, we can identify the part of that
activity that the person carried out and assert a role classification on it
via P2_has_type.

Rob


On Mon, May 8, 2023 at 9:44 AM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear All,
>
> I don't think it is correct to make the PC classes entities. Even though
> formally an RDF class could be regarded as an entity, ontologically we
> distinguish entities and relationships. The E-R paradigm makes this
> distinction also formally clear. We model the properties with .1 properties
> in FOL as n-ary relationships, and not as individuals.
>
> Making the PC classes CRM Entities is inconsistent with the FOL
> definition, which is the proper formalization.
> In other words, we would make a workaround for a missing feature in RDFS
> an ontological argument. We are again in the discussion to take RDFS as the
> definition of the CRM, and not as an implementation.
>
> As a first step, we could introduce an "E0 CRM Relation", which would have
> as instances all properties and the PC classes. The ontological distinction
> between relations and entities is fundamental to the methodology of
> ontological analysis.
>
> As a second step, we can start to investigate to which degree PC classes
> qualify as ontological individuals in their own right. If we start
> declaring a priori all PC classes as entities, we have later to justify and
> remove all those that are relations in the true sense.  For instance, I
> cannot imagine the "being part of" a Physical Object for some time to
> become an entity, because it needs a timespan.
>
> Best,
>
> Martin
>
> On 5/8/2023 12:54 PM, George Bruseker via Crm-sig wrote:
>
> Hi all,
>
> I would argue that the safest thing to do is to make the PCs a subclass of
> E1 and then see where we go from there. I agree with Martin that it can't
> be an information object (because everything would be then) but I imagine
> we would have a debate about what each .1 actually ontologically is. What
> is certain is that by virtue of the fact of being something said in the
> universe of CIDOC CRM it is something sayable / mentionable. This is what
> E1 gives us, the most vague point of an object that can be pointed to and
> named, possibly classified. The problem is right now that we have something
> that is sayable in CIDOC CRM (PCxxx) but it is not referenceable. But this
> is a logical contradiction. Everything that can be said can be referenced
> and PCxxx can definitely be said.
>
> For example, if I say that Bob was involved in the Production of Mona Lisa
> as Creator then this is something said / stated that is important, that has
> a real world referent, which has a definite meaning which is true or false
> etc. Ergo, it requires provenance. The basic mechanism for provenance in
> CRMbase is E13 and indicates that there was an agency behind something
> being asserted of something else.
>
> Here the thing we want to talk about is the role and the role IS an
> instance of PC14. It's already an instance of a class so it should be
> referenceable. (Also one might like to put a bibliography for people who
> thought that Bob was Creator of Mona Lisa etc.)
>
> So I would go exactly for Paulos' modelling but with this change:
>
> :painting_sistine_chapel
>  crm:P01i_is_domain_of :role_of_michaelangeo_in_sistene_chapel_project
>
> :role_of_michaelangeo_in_sistene_chapel_project
>a crm:PC14_carried_out_by ;
>crm:P02_has_range :Michelangelo  ;
>crm:P14.1_in_the_role_of  :master_craftsman .
> :attrAssign1
>a crm:E13_Attribute_Assignment ;
>crm:P140_assigned_attribute_to
> :role_of_michaelangeo_in_sistene_chapel_project
>... ... ...
>
>
> On Mon, May 8, 2023 at 10:42 AM athinak  wrote:
>
>> Dear George, all,
>>
>>   I am not sure that the class PC0_Typed_CRM_Property should be a
>> subclass of E1. In my understanding, this class implies a situation
>> concluded in an epistemological context. I am also not sure if the
>> provenance we are looking for in this set of statements is a kind of
>> E13. I am just wondering.
>>
>> BRs,
>> Athina
>>
>>
>>   On 2023-03-29 16:36, George Bruseker via Crm-sig 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Martin Doerr via Crm-sig]

Dear All,

I don't think it is correct to make the PC classes entities. Even though 
formally an RDF class could be regarded as an entity, ontologically we 
distinguish entities and relationships. The E-R paradigm makes this 
distinction also formally clear. We model the properties with .1 
properties in FOL as n-ary relationships, and not as individuals.


Making the PC classes CRM Entities is inconsistent with the FOL 
definition, which is the proper formalization.
In other words, we would make a workaround for a missing feature in RDFS 
an ontological argument. We are again in the discussion to take RDFS as 
the definition of the CRM, and not as an implementation.


As a first step, we could introduce an "E0 CRM Relation", which would 
have as instances all properties and the PC classes. The ontological 
distinction between relations and entities is fundamental to the 
methodology of ontological analysis.


As a second step, we can start to investigate to which degree PC classes 
qualify as ontological individuals in their own right. If we start 
declaring a priori all PC classes as entities, we have later to justify 
and remove all those that are relations in the true sense.  For 
instance, I cannot imagine the "being part of" a Physical Object for 
some time to become an entity, because it needs a timespan.


Best,

Martin

On 5/8/2023 12:54 PM, George Bruseker via Crm-sig wrote:

Hi all,

I would argue that the safest thing to do is to make the PCs a 
subclass of E1 and then see where we go from there. I agree with 
Martin that it can't be an information object (because everything 
would be then) but I imagine we would have a debate about what each .1 
actually ontologically is. What is certain is that by virtue of the 
fact of being something said in the universe of CIDOC CRM it is 
something sayable / mentionable. This is what E1 gives us, the most 
vague point of an object that can be pointed to and named, possibly 
classified. The problem is right now that we have something that is 
sayable in CIDOC CRM (PCxxx) but it is not referenceable. But this is 
a logical contradiction. Everything that can be said can be referenced 
and PCxxx can definitely be said.


For example, if I say that Bob was involved in the Production of Mona 
Lisa as Creator then this is something said / stated that is 
important, that has a real world referent, which has a definite 
meaning which is true or false etc. Ergo, it requires provenance. The 
basic mechanism for provenance in CRMbase is E13 and indicates that 
there was an agency behind something being asserted of something else.


Here the thing we want to talk about is the role and the role IS an 
instance of PC14. It's already an instance of a class so it should be 
referenceable. (Also one might like to put a bibliography for people 
who thought that Bob was Creator of Mona Lisa etc.)


So I would go exactly for Paulos' modelling but with this change:

:painting_sistine_chapel
crm:P01i_is_domain_of :role_of_michaelangeo_in_sistene_chapel_project

:role_of_michaelangeo_in_sistene_chapel_project
   a crm:PC14_carried_out_by ;
   crm:P02_has_range :Michelangelo  ;
   crm:P14.1_in_the_role_of  :master_craftsman .
:attrAssign1
   a crm:E13_Attribute_Assignment ;
   crm:P140_assigned_attribute_to 
:role_of_michaelangeo_in_sistene_chapel_project

   ... ... ...


On Mon, May 8, 2023 at 10:42 AM athinak  wrote:

Dear George, all,

  I am not sure that the class PC0_Typed_CRM_Property should be a
subclass of E1. In my understanding, this class implies a situation
concluded in an epistemological context. I am also not sure if the
provenance we are looking for in this set of statements is a kind of
E13. I am just wondering.

BRs,
Athina


  On 2023-03-29 16:36, George Bruseker via Crm-sig wrote:
> Dear all,
>
> When using the PC classes modelling structure we end up with a class
> node for a property which we can then modify with things like
'kinds'
> and 'modes' etc.
>
> Since such a statement has meaning and comes from somewhere [e.g.:
> that someone did something in some capacity (PC14 carried out by ...
> P02 has range E39 + P14.1 in the role of E55)] one sometimes
needs to
> provenance this statement with an E13 attribute assignment. Ie
we want
> to ground who made this claim.
>
> In theory this would be done with E13 pointing to the node in the
> typical fashion (p141, P140). However, the class
> PC0_Typed_CRM_Property is not declared as a subtype of E1 CRM Entity
> in the PC extension file. As a result we cannot do this.
>
> https://cidoc-crm.org/rdfs/7.1.1/CIDOC_CRM_v7.1.1_PC.rdfs
>
> I would argue PC0_Typed_CRM_Property should be declared a
subclass of
> E1_CRM_Entity.  Then it would be consistent with the rest of the
> modelling.
>
> Opinions?
>
> Best,
>
> George
> 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[George Bruseker via Crm-sig]

Hi all,

I would argue that the safest thing to do is to make the PCs a subclass of
E1 and then see where we go from there. I agree with Martin that it can't
be an information object (because everything would be then) but I imagine
we would have a debate about what each .1 actually ontologically is. What
is certain is that by virtue of the fact of being something said in the
universe of CIDOC CRM it is something sayable / mentionable. This is what
E1 gives us, the most vague point of an object that can be pointed to and
named, possibly classified. The problem is right now that we have something
that is sayable in CIDOC CRM (PCxxx) but it is not referenceable. But this
is a logical contradiction. Everything that can be said can be referenced
and PCxxx can definitely be said.

For example, if I say that Bob was involved in the Production of Mona Lisa
as Creator then this is something said / stated that is important, that has
a real world referent, which has a definite meaning which is true or false
etc. Ergo, it requires provenance. The basic mechanism for provenance in
CRMbase is E13 and indicates that there was an agency behind something
being asserted of something else.

Here the thing we want to talk about is the role and the role IS an
instance of PC14. It's already an instance of a class so it should be
referenceable. (Also one might like to put a bibliography for people who
thought that Bob was Creator of Mona Lisa etc.)

So I would go exactly for Paulos' modelling but with this change:

:painting_sistine_chapel
 crm:P01i_is_domain_of :role_of_michaelangeo_in_sistene_chapel_project

:role_of_michaelangeo_in_sistene_chapel_project
   a crm:PC14_carried_out_by ;
   crm:P02_has_range :Michelangelo  ;
   crm:P14.1_in_the_role_of  :master_craftsman .
:attrAssign1
   a crm:E13_Attribute_Assignment ;
   crm:P140_assigned_attribute_to
:role_of_michaelangeo_in_sistene_chapel_project
   ... ... ...


On Mon, May 8, 2023 at 10:42 AM athinak  wrote:

> Dear George, all,
>
>   I am not sure that the class PC0_Typed_CRM_Property should be a
> subclass of E1. In my understanding, this class implies a situation
> concluded in an epistemological context. I am also not sure if the
> provenance we are looking for in this set of statements is a kind of
> E13. I am just wondering.
>
> BRs,
> Athina
>
>
>   On 2023-03-29 16:36, George Bruseker via Crm-sig wrote:
> > Dear all,
> >
> > When using the PC classes modelling structure we end up with a class
> > node for a property which we can then modify with things like 'kinds'
> > and 'modes' etc.
> >
> > Since such a statement has meaning and comes from somewhere [e.g.:
> > that someone did something in some capacity (PC14 carried out by ...
> > P02 has range E39 + P14.1 in the role of E55)] one sometimes needs to
> > provenance this statement with an E13 attribute assignment. Ie we want
> > to ground who made this claim.
> >
> > In theory this would be done with E13 pointing to the node in the
> > typical fashion (p141, P140). However, the class
> > PC0_Typed_CRM_Property is not declared as a subtype of E1 CRM Entity
> > in the PC extension file. As a result we cannot do this.
> >
> > https://cidoc-crm.org/rdfs/7.1.1/CIDOC_CRM_v7.1.1_PC.rdfs
> >
> > I would argue PC0_Typed_CRM_Property should be declared a subclass of
> > E1_CRM_Entity.  Then it would be consistent with the rest of the
> > modelling.
> >
> > Opinions?
> >
> > Best,
> >
> > George
> > ___
> > 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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Pavlos Fafalios via Crm-sig]

Dear Martin,

I see your point, thank you for the explanation. Maybe, this was also the
motivation for introducing the property classes? (instead of using standard
rdf reification): an instance of a property class intends to represent a
specific relation in the real world, not a triple/statement in a knowledge
base (as in the case of rdf:Statement
: *"An RDF statement
is the statement made by a token of an RDF triple"*). If this is the case,
I suggest including an explanation in the RDFS of the PCs.

Best,
Pavlos

On Sat, May 6, 2023 at 9:57 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Pavlos,
>
> I don't think this is a good solution. Every statement in a knowledge base
> is an information object. That does not say however, what it refers to in
> the universe of discourse (or real world). The identity of the information
> object is the RDF file. The identity of Michelangelo, as stated in the
> file, means Michelangelo the person and not the URI as a string in that
> file. Isn't it?
>
> This is still an issue to resolve: In CRMinf, a Proposition Set is
> regarded as Information Object, but this is not what we actually mean, we
> mean the "meaning" of that Information Object, i.e., its truth or not. As
> such, CRMinf is inconsistent. This is, I think, Issue 614.
>
> Best,
>
> Martin
>
> On 5/6/2023 12:43 AM, Pavlos Fafalios via Crm-sig wrote:
>
> Dear George,
>
> An instance of a property class represents a statement / formal
> proposition. Could we thus say that it is also an  E73 Information Object?
> Would multiple instantiation provide a solution to the problem you
> describe? E.g.:
>
> :painting_sistine_chapel
>  crm:P14_carried_out_by :Michelangelo .
> *:statement1*
>a crm:PC14_carried_out_by,  *crm:E73_Information_Object* ;
>crm:P01_has_domain :painting_sistine_chapel ;
>crm:P02_has_range :Michelangelo  ;
>crm:P14.1_in_the_role_of  :master_craftsman .
> :attrAssign1
>a crm:E13_Attribute_Assignment ;
>crm:P140_assigned_attribute_to *:statement1*
>... ... ...
>
> Thoughts?
>
> Have a good weekend!
>
> Best,
> Pavlos
>
> On Wed, Mar 29, 2023 at 4:36 PM George Bruseker via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> Dear all,
>>
>> When using the PC classes modelling structure we end up with a class node
>> for a property which we can then modify with things like 'kinds' and
>> 'modes' etc.
>>
>> Since such a statement has meaning and comes from somewhere [e.g.: that
>> someone did something in some capacity (PC14 carried out by ... P02 has
>> range E39 + P14.1 in the role of E55)] one sometimes needs to provenance
>> this statement with an E13 attribute assignment. Ie we want to ground who
>> made this claim.
>>
>> In theory this would be done with E13 pointing to the node in the typical
>> fashion (p141, P140). However, the class PC0_Typed_CRM_Property is not
>> declared as a subtype of E1 CRM Entity in the PC extension file. As a
>> result we cannot do this.
>>
>> https://cidoc-crm.org/rdfs/7.1.1/CIDOC_CRM_v7.1.1_PC.rdfs
>>
>> I would argue PC0_Typed_CRM_Property should be declared a subclass of
>> E1_CRM_Entity.  Then it would be consistent with the rest of the modelling.
>>
>> Opinions?
>>
>> Best,
>>
>> George
>> ___
>> 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 
> 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
>


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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[athinak via Crm-sig]

Dear George, all,

 I am not sure that the class PC0_Typed_CRM_Property should be a 
subclass of E1. In my understanding, this class implies a situation 
concluded in an epistemological context. I am also not sure if the 
provenance we are looking for in this set of statements is a kind of 
E13. I am just wondering.


BRs,
Athina


 On 2023-03-29 16:36, George Bruseker via Crm-sig wrote:

Dear all,

When using the PC classes modelling structure we end up with a class
node for a property which we can then modify with things like 'kinds'
and 'modes' etc.

Since such a statement has meaning and comes from somewhere [e.g.:
that someone did something in some capacity (PC14 carried out by ...
P02 has range E39 + P14.1 in the role of E55)] one sometimes needs to
provenance this statement with an E13 attribute assignment. Ie we want
to ground who made this claim.

In theory this would be done with E13 pointing to the node in the
typical fashion (p141, P140). However, the class
PC0_Typed_CRM_Property is not declared as a subtype of E1 CRM Entity
in the PC extension file. As a result we cannot do this.

https://cidoc-crm.org/rdfs/7.1.1/CIDOC_CRM_v7.1.1_PC.rdfs

I would argue PC0_Typed_CRM_Property should be declared a subclass of
E1_CRM_Entity.  Then it would be consistent with the rest of the
modelling.

Opinions?

Best,

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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Martin Doerr via Crm-sig]

Dear Pavlos,

I don't think this is a good solution. Every statement in a knowledge 
base is an information object. That does not say however, what it refers 
to in the universe of discourse (or real world). The identity of the 
information object is the RDF file. The identity of Michelangelo, as 
stated in the file, means Michelangelo the person and not the URI as a 
string in that file. Isn't it?


This is still an issue to resolve: In CRMinf, a Proposition Set is 
regarded as Information Object, but this is not what we actually mean, 
we mean the "meaning" of that Information Object, i.e., its truth or 
not. As such, CRMinf is inconsistent. This is, I think, Issue 614.


Best,

Martin

On 5/6/2023 12:43 AM, Pavlos Fafalios via Crm-sig wrote:

Dear George,

An instance of a property class represents a statement / formal 
proposition. Could we thus say that it is also an  E73 Information Object?
Would multiple instantiation provide a solution to the problem you 
describe? E.g.:


:painting_sistine_chapel
     crm:P14_carried_out_by :Michelangelo .
*:statement1*
   a crm:PC14_carried_out_by, *crm:E73_Information_Object* ;
   crm:P01_has_domain :painting_sistine_chapel ;
   crm:P02_has_range :Michelangelo  ;
   crm:P14.1_in_the_role_of  :master_craftsman .
:attrAssign1
   a crm:E13_Attribute_Assignment ;
   crm:P140_assigned_attribute_to *:statement1*
   ... ... ...
Thoughts?

Have a good weekend!

Best,
Pavlos

On Wed, Mar 29, 2023 at 4:36 PM George Bruseker via Crm-sig 
 wrote:


Dear all,

When using the PC classes modelling structure we end up with a
class node for a property which we can then modify with things
like 'kinds' and 'modes' etc.

Since such a statement has meaning and comes from somewhere [e.g.:
that someone did something in some capacity (PC14 carried out by
... P02 has range E39 + P14.1 in the role of E55)] one sometimes
needs to provenance this statement with an E13 attribute
assignment. Ie we want to ground who made this claim.

In theory this would be done with E13 pointing to the node in the
typical fashion (p141, P140). However, the
class PC0_Typed_CRM_Property is not declared as a subtype of E1
CRM Entity in the PC extension file. As a result we cannot do this.

https://cidoc-crm.org/rdfs/7.1.1/CIDOC_CRM_v7.1.1_PC.rdfs

I would argue PC0_Typed_CRM_Property should be declared a subclass
of E1_CRM_Entity.  Then it would be consistent with the rest of
the modelling.

Opinions?

Best,

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



--

 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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Pavlos Fafalios via Crm-sig]

Dear George,

An instance of a property class represents a statement / formal
proposition. Could we thus say that it is also an  E73 Information Object?
Would multiple instantiation provide a solution to the problem you
describe? E.g.:

:painting_sistine_chapel
 crm:P14_carried_out_by :Michelangelo .
*:statement1*
   a crm:PC14_carried_out_by,  *crm:E73_Information_Object* ;
   crm:P01_has_domain :painting_sistine_chapel ;
   crm:P02_has_range :Michelangelo  ;
   crm:P14.1_in_the_role_of  :master_craftsman .
:attrAssign1
   a crm:E13_Attribute_Assignment ;
   crm:P140_assigned_attribute_to *:statement1*
   ... ... ...

Thoughts?

Have a good weekend!

Best,
Pavlos

On Wed, Mar 29, 2023 at 4:36 PM George Bruseker via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> When using the PC classes modelling structure we end up with a class node
> for a property which we can then modify with things like 'kinds' and
> 'modes' etc.
>
> Since such a statement has meaning and comes from somewhere [e.g.: that
> someone did something in some capacity (PC14 carried out by ... P02 has
> range E39 + P14.1 in the role of E55)] one sometimes needs to provenance
> this statement with an E13 attribute assignment. Ie we want to ground who
> made this claim.
>
> In theory this would be done with E13 pointing to the node in the typical
> fashion (p141, P140). However, the class PC0_Typed_CRM_Property is not
> declared as a subtype of E1 CRM Entity in the PC extension file. As a
> result we cannot do this.
>
> https://cidoc-crm.org/rdfs/7.1.1/CIDOC_CRM_v7.1.1_PC.rdfs
>
> I would argue PC0_Typed_CRM_Property should be declared a subclass of
> E1_CRM_Entity.  Then it would be consistent with the rest of the modelling.
>
> Opinions?
>
> Best,
>
> George
> ___
> 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