Re: [Crm-sig] ISSUE 588 Implementing the .1 Properties of Base and Extensions in RDF

[Pavlos Fafalios via Crm-sig]

Dear Francesco,

You have raised some interesting points which, I think, need discussion
(but after closing this issue ), including:
- what was the motivation of introducing property classes
- how can we tackle ambiguity of PCs (classes vs properties, etc etc)
- why not directly using the standard RDF reification vocabulary
, where properties
can be attached to statements/triples.
I will include your comments in the working document of Issue 588, with a
suggestion to open a new issue for discussing and working on them.

Best regards,
Pavlos


On Tue, Dec 6, 2022 at 8:39 PM Francesco Beretta via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Pavlos, all
>
> reconsidering this question of the properties of properties and the
> proposed solution of the properties-classes remain some doubts and
> interrogations to me, in particular in relation with the best practices in
> the field of serialization of conceptual models in RDF.
>
> Metadata about properties as instances, i.e. statement, can be expressed
> with the standard RDF reification or the new RDF* standard.
>
> What is the best practice in the RDF community to express this kind of
> properties of properties (and also dates, etc. added to properties in
> conceptual models) ?
>
>
> And furthermore: are the CRM properties of properties just 'metadata' or
> do they carry some additional ontological substance ?
>
> The technical solution of 'PC' does not remove all ambiguity: are they in
> the end properties or classes? and when we talk about adding, as now,
> labels and scope notes to the PCs they do becomes classes, don't they? what
> is then their substance? just to be reified properties?
>
> One could come to think that in fact there is more substance but not
> totally and adequately expressed, and that should be more carefully
> analyzed like in the case of P14.1 in the role of: E55 Type or P107.1 kind
> of member: E55 Type.
>
> Take the example of  P3.1 has type: E55 Type — "This property allows
> differentiation of specific notes, e.g., “construction”, “decoration” etc."
> (thank you Pavlos for the work you've done).
>
> If P3 is not just taken as a CRM replacement of *rdfs:comment*, shouldn't
> the so called associated 'note' be modelled as an information object of
> type 'damage description' (chipped at edge of handle) related to the
> corresponding human-made object by P129 is about. Or 'chipped at edge of
> handle' would be a E3 Condition or State and the 'note' its description?
>
> But because P3 has E62 String as a range, which "is not further elaborated
> upon within the model", it becomes —P3 I mean— quite relevant as it
> captures the characterization of the item itself, its internal structures,
> appearance etc.
>
> So, again, are there any best practices in other communities of RDF
> experts that apply to these types of situations that should be analyzed
> before further specifying a notion of PC that doesn't seem totally
> justified, or raising ontological analisis issues, instead of using simple
> RDF reification?
>
> Best
>
> Francesco
>
> Le 01.12.22 à 17:35, Pavlos Fafalios via Crm-sig a écrit :
>
> Dear all,
>
> Please find my revised homework for issue 588
> 
> below:
>
> https://drive.google.com/drive/folders/1b0wW70xo2wjxNlWHYDRl7nr-fzYXTchN?usp=share_link
>
> Feel free to add your comments or send your feedback!
>
> Best regards,
> Pavlos
>
> On Tue, Sep 13, 2022 at 11:23 AM Pavlos Fafalios 
> wrote:
>
>> Dear Mark, all,
>>
>> I agree, we need to make clear which constructs of the RDF are not part
>> of CIDOC-CRM (especially since they make use of the same namespace).
>> One way is to add a note in the beginning of the file. Another way would
>> be to provide them through a different namespace (not sure if this is a
>> good solution--needs some thinking).
>>
>> This is also a good reason for having them in a different RDF file:  all
>> classes and properties in this file, except the .1 properties, are not part
>> of CIDOC-CRM, while the .1 properties have a 'domain' class that is also
>> not part of CIDOC-CRM.
>>
>> Best,
>> Pavlos
>>
>> On Mon, Sep 12, 2022 at 5:53 PM Mark Fichtner 
>> wrote:
>>
>>> Dear all,
>>>
>>> nice work, thanks! I think for RDF this is a valid representation,
>>> although I am not very happy to add properties that are not in the cidoc
>>> crm directly and that are not part of the language itself (like in this
>>> case crm:P03_reifies). As a user/reader of the rdf it is simply hard to
>>> understand what is part of the cidoc crm itself and what comes due to
>>> "workarounds". Even in as a new ontology/file/addon it mixes cidoc crm and
>>> non-cidoc crm things.
>>>
>>> Also we have a reification concept (E13 Attribute Assignment), I am not
>>> sure if we need even more of these.
>>>
>>> I'm looking forward to the discussion!
>>>
>>> 

Re: [Crm-sig] ISSUE Implementing .2 Properties in RDF

[Martin Doerr via Crm-sig]

Dear George,

I agree that often links with properties simplify a more complex entity. 
There are complex questions of the philosophical distinction between 
relationships and the entities that exist by their own. E-R model and 
RDFS differ considerably in this respect. Regarding the question of 
"state", I think the use of the term itself suggests a simplicity that 
does not exist. We have discussed extensively concepts of state and 
situation, without coming to a clear unique definition of what it can 
mean. In the extreme, we can regard any property instance as a kind of 
"state".


I see the question more practical, to model all these intermediate 
things explicitly as distinct, in a proactive way,  would need a lot of 
effort, without a clear demand. Also, there is the question, where to 
stop the intermediate of the intermediate of the intermediate entity. 
With respect to the statigraphic relations below, I do not agree that 
there are hidden entities. Simply, I regard this "directed 
correspondence" construct to be of /epistemic /nature, and it is missing 
as primitive in the KR languages we use.


All the best,

Martin

On 5/2/2023 3:08 PM, George Bruseker via Crm-sig wrote:

Dear both,

I am more and more swayed by Francesco's argument that every PC 
property class hides an actual ontological entity which we are failing 
to properly model.


I think in principle what Pavlos proposes is syntactically correct and 
insofar as we stay on PC here that is probably the way to go.


That said, in this case we are actually building PCs on PCs 
essentially because we want to avoid saying that there is a state that 
exists or existed between two things and held for some time. Perhaps 
in a later version of archaeo if we are able to accept that states do 
exist we could significantly simplify this model by having real state 
classes for physical relations etc. This I just forward for thought. 
The present modelling completely depends on PC properties and there 
would be no good reason to pause the present development path of 
CRMArchaeo which is reaching a stable point, by presently changing 
course. We can maintain the state we presently have.


Best,

George

On Tue, May 2, 2023 at 1:55 PM Pavlos Fafalios via Crm-sig 
 wrote:


Dear Gerald, all,

I think we can follow the same reification approach as we do for
the .1 properties.
In this case, we just need to provide the property classes of the
domain and range properties of AP13.2, i.e.:
    PC_AP13_has_stratigraphic_relation_to
and
    PC_AP11_has_physical_relation_to

Then, here is a (draft) example of RDF triples that make use of
these constructs:

***

   a   .

   a   .


     .

   a  ;
     ;
     .


     .

   a  ;
     ;
     .


      
***

But there are also other approaches for implementing this, such as
using named graphs, or the standard RDF reification method (i.e.
using rdf:subject, rdf:object, etc.), or RDF-start (I think).

Please correct me if I have misunderstood something!

Best regards,
Pavlos

On Mon, Apr 24, 2023 at 3:38 PM Hiebel, Gerald via Crm-sig
 wrote:

Dear all,

we discussed CRMarchaeo and are going to make a proposel for a
new version in the next CRM-SIG.

In the discussion we encountered the issue of not having yet a
policy/strategy for implementing .2 properties which means
properties related to properties.

We have one of them in CRMarchaeo:

*AP13.2 justified by (is justification of)***

Domain: _AP13_has stratigraphic relation to

Range: _AP11_has physical relation to

Scope note: This property identifies the type of physical
relation that was used to justify the type  of stratigraphic
relation assigned to the relation between two A5

Stratigraphic
Modification events. Physical relations of “above” or “fills”
may justify the stratigraphic relation type “after”. Figure 7
gives a graphical representation and Figure 6 shows an example.

I would ask to either create a new issue for the
implementation of .2 properties or include the discussion in
the existing issue 588 as the strategy should be the same for
.1 and .2 .

Whatever you think appropriate.

Kind regards,

Gerald

*From: *Crm-sig  on behalf of
Pavlos Fafalios via Crm-sig 
*Reply to: *Pavlos Fafalios 
*Date: *Thursday, 1. December 2022 at 17:46
*To: *crm-sig 
*Subject: *Re: [Crm-sig] ISSUE 588 Implementing the .1
Properties of Base and Extensions in RDF

   

Re: [Crm-sig] ISSUE Implementing .2 Properties in RDF

[George Bruseker via Crm-sig]

Hi Pavlos,

I definitely agree to keep following the PC modelling pattern at this
moment and your RDF description above looks correct to me.

My point was a theoretic one. The spirit should be to come to a conclusion
on this issue given current premises. My comments for posterity not the
present :) Or perhaps as Gerald implied the .2 as a method could be a
separate issue, while this particular implementation could just go ahead as
is.

Cheers,

George

On Tue, May 2, 2023 at 4:09 PM Pavlos Fafalios 
wrote:

> Dear George,
>
> About the PC constructs and, in general, if this is the best method to
> implement CRM's properties of properties in RDF (considering Francesco's
> email and arguments): I was not involved in the initial discussions, when
> the SIG first introduced the idea of property classes for implementing the
> .1 properties of CRM (I see they were first introduced in Jan 2015 for crm
> version 6.0). My suggestion is to first close issue 588
> 
>  *(since we have already voted for most of its sub-issues*) and then open
> a new issue for discussing this aspect.
>
> Thoughts?
>
> Best,
> Pavlos
>
>
> On Tue, May 2, 2023 at 3:08 PM George Bruseker 
> wrote:
>
>> Dear both,
>>
>> I am more and more swayed by Francesco's argument that every PC property
>> class hides an actual ontological entity which we are failing to properly
>> model.
>>
>> I think in principle what Pavlos proposes is syntactically correct and
>> insofar as we stay on PC here that is probably the way to go.
>>
>> That said, in this case we are actually building PCs on PCs essentially
>> because we want to avoid saying that there is a state that exists or
>> existed between two things and held for some time. Perhaps in a later
>> version of archaeo if we are able to accept that states do exist we could
>> significantly simplify this model by having real state classes for physical
>> relations etc. This I just forward for thought. The present modelling
>> completely depends on PC properties and there would be no good reason to
>> pause the present development path of CRMArchaeo which is reaching a stable
>> point, by presently changing course. We can maintain the state we presently
>> have.
>>
>> Best,
>>
>> George
>>
>> On Tue, May 2, 2023 at 1:55 PM Pavlos Fafalios via Crm-sig <
>> crm-sig@ics.forth.gr> wrote:
>>
>>> Dear Gerald, all,
>>>
>>> I think we can follow the same reification approach as we do for the .1
>>> properties.
>>> In this case, we just need to provide the property classes of the domain
>>> and range properties of AP13.2, i.e.:
>>> PC_AP13_has_stratigraphic_relation_to
>>> and
>>> PC_AP11_has_physical_relation_to
>>>
>>> Then, here is a (draft) example of RDF triples that make use of these
>>> constructs:
>>>
>>> ***
>>> 
>>>a   .
>>> 
>>>a   .
>>>
>>> 
>>>  .
>>> 
>>>a  ;
>>>  ;
>>>  .
>>>
>>> 
>>>  .
>>> 
>>>a  ;
>>>  ;
>>>  .
>>>
>>> 
>>>   
>>> ***
>>>
>>> But there are also other approaches for implementing this, such as using
>>> named graphs, or the standard RDF reification method (i.e. using
>>> rdf:subject, rdf:object, etc.), or RDF-start (I think).
>>>
>>> Please correct me if I have misunderstood something!
>>>
>>> Best regards,
>>> Pavlos
>>>
>>> On Mon, Apr 24, 2023 at 3:38 PM Hiebel, Gerald via Crm-sig <
>>> crm-sig@ics.forth.gr> wrote:
>>>
 Dear all,

 we discussed CRMarchaeo and are going to make a proposel for a new
 version in the next CRM-SIG.



 In the discussion we encountered the issue of not having yet a
 policy/strategy for implementing .2 properties which means properties
 related to properties.

 We have one of them in CRMarchaeo:

 *AP13.2 justified by (is justification of)*



 Domain:*AP13* has stratigraphic relation to

 Range:   *AP11* has physical relation to



 Scope note:   This property identifies the type of physical
 relation that was used to justify the type  of stratigraphic relation
 assigned to the relation between two A5
 
 Stratigraphic Modification events. Physical relations of “above” or “fills”
 may justify the stratigraphic relation type “after”. Figure 7 gives a
 graphical representation and Figure 6 shows an example.





 I would ask to either create a new issue for the implementation of .2
 properties or include the discussion in the existing issue 588 as the
 strategy should be the same for .1 and .2 .

 Whatever you think appropriate.



 Kind regards,

 

Re: [Crm-sig] ISSUE Implementing .2 Properties in RDF

[Pavlos Fafalios via Crm-sig]

Dear George,

About the PC constructs and, in general, if this is the best method to
implement CRM's properties of properties in RDF (considering Francesco's
email and arguments): I was not involved in the initial discussions, when
the SIG first introduced the idea of property classes for implementing the
.1 properties of CRM (I see they were first introduced in Jan 2015 for crm
version 6.0). My suggestion is to first close issue 588

 *(since we have already voted for most of its sub-issues*) and then open a
new issue for discussing this aspect.

Thoughts?

Best,
Pavlos


On Tue, May 2, 2023 at 3:08 PM George Bruseker 
wrote:

> Dear both,
>
> I am more and more swayed by Francesco's argument that every PC property
> class hides an actual ontological entity which we are failing to properly
> model.
>
> I think in principle what Pavlos proposes is syntactically correct and
> insofar as we stay on PC here that is probably the way to go.
>
> That said, in this case we are actually building PCs on PCs essentially
> because we want to avoid saying that there is a state that exists or
> existed between two things and held for some time. Perhaps in a later
> version of archaeo if we are able to accept that states do exist we could
> significantly simplify this model by having real state classes for physical
> relations etc. This I just forward for thought. The present modelling
> completely depends on PC properties and there would be no good reason to
> pause the present development path of CRMArchaeo which is reaching a stable
> point, by presently changing course. We can maintain the state we presently
> have.
>
> Best,
>
> George
>
> On Tue, May 2, 2023 at 1:55 PM Pavlos Fafalios via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> Dear Gerald, all,
>>
>> I think we can follow the same reification approach as we do for the .1
>> properties.
>> In this case, we just need to provide the property classes of the domain
>> and range properties of AP13.2, i.e.:
>> PC_AP13_has_stratigraphic_relation_to
>> and
>> PC_AP11_has_physical_relation_to
>>
>> Then, here is a (draft) example of RDF triples that make use of these
>> constructs:
>>
>> ***
>> 
>>a   .
>> 
>>a   .
>>
>> 
>>  .
>> 
>>a  ;
>>  ;
>>  .
>>
>> 
>>  .
>> 
>>a  ;
>>  ;
>>  .
>>
>> 
>>   
>> ***
>>
>> But there are also other approaches for implementing this, such as using
>> named graphs, or the standard RDF reification method (i.e. using
>> rdf:subject, rdf:object, etc.), or RDF-start (I think).
>>
>> Please correct me if I have misunderstood something!
>>
>> Best regards,
>> Pavlos
>>
>> On Mon, Apr 24, 2023 at 3:38 PM Hiebel, Gerald via Crm-sig <
>> crm-sig@ics.forth.gr> wrote:
>>
>>> Dear all,
>>>
>>> we discussed CRMarchaeo and are going to make a proposel for a new
>>> version in the next CRM-SIG.
>>>
>>>
>>>
>>> In the discussion we encountered the issue of not having yet a
>>> policy/strategy for implementing .2 properties which means properties
>>> related to properties.
>>>
>>> We have one of them in CRMarchaeo:
>>>
>>> *AP13.2 justified by (is justification of)*
>>>
>>>
>>>
>>> Domain:*AP13* has stratigraphic relation to
>>>
>>> Range:   *AP11* has physical relation to
>>>
>>>
>>>
>>> Scope note:   This property identifies the type of physical
>>> relation that was used to justify the type  of stratigraphic relation
>>> assigned to the relation between two A5
>>> 
>>> Stratigraphic Modification events. Physical relations of “above” or “fills”
>>> may justify the stratigraphic relation type “after”. Figure 7 gives a
>>> graphical representation and Figure 6 shows an example.
>>>
>>>
>>>
>>>
>>>
>>> I would ask to either create a new issue for the implementation of .2
>>> properties or include the discussion in the existing issue 588 as the
>>> strategy should be the same for .1 and .2 .
>>>
>>> Whatever you think appropriate.
>>>
>>>
>>>
>>> Kind regards,
>>>
>>> Gerald
>>>
>>>
>>>
>>> *From: *Crm-sig  on behalf of Pavlos
>>> Fafalios via Crm-sig 
>>> *Reply to: *Pavlos Fafalios 
>>> *Date: *Thursday, 1. December 2022 at 17:46
>>> *To: *crm-sig 
>>> *Subject: *Re: [Crm-sig] ISSUE 588 Implementing the .1 Properties of
>>> Base and Extensions in RDF
>>>
>>>
>>>
>>> Dear all,
>>>
>>>
>>>
>>> Please find my revised homework for issue 588
>>> 
>>> below:
>>>
>>>
>>> https://drive.google.com/drive/folders/1b0wW70xo2wjxNlWHYDRl7nr-fzYXTchN?usp=share_link
>>>
>>>
>>>
>>> Feel free to add your comments or send 

Re: [Crm-sig] ISSUE Implementing .2 Properties in RDF

[George Bruseker via Crm-sig]

Dear both,

I am more and more swayed by Francesco's argument that every PC property
class hides an actual ontological entity which we are failing to properly
model.

I think in principle what Pavlos proposes is syntactically correct and
insofar as we stay on PC here that is probably the way to go.

That said, in this case we are actually building PCs on PCs essentially
because we want to avoid saying that there is a state that exists or
existed between two things and held for some time. Perhaps in a later
version of archaeo if we are able to accept that states do exist we could
significantly simplify this model by having real state classes for physical
relations etc. This I just forward for thought. The present modelling
completely depends on PC properties and there would be no good reason to
pause the present development path of CRMArchaeo which is reaching a stable
point, by presently changing course. We can maintain the state we presently
have.

Best,

George

On Tue, May 2, 2023 at 1:55 PM Pavlos Fafalios via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Gerald, all,
>
> I think we can follow the same reification approach as we do for the .1
> properties.
> In this case, we just need to provide the property classes of the domain
> and range properties of AP13.2, i.e.:
> PC_AP13_has_stratigraphic_relation_to
> and
> PC_AP11_has_physical_relation_to
>
> Then, here is a (draft) example of RDF triples that make use of these
> constructs:
>
> ***
> 
>a   .
> 
>a   .
>
> 
>  .
> 
>a  ;
>  ;
>  .
>
> 
>  .
> 
>a  ;
>  ;
>  .
>
> 
>   
> ***
>
> But there are also other approaches for implementing this, such as using
> named graphs, or the standard RDF reification method (i.e. using
> rdf:subject, rdf:object, etc.), or RDF-start (I think).
>
> Please correct me if I have misunderstood something!
>
> Best regards,
> Pavlos
>
> On Mon, Apr 24, 2023 at 3:38 PM Hiebel, Gerald via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> Dear all,
>>
>> we discussed CRMarchaeo and are going to make a proposel for a new
>> version in the next CRM-SIG.
>>
>>
>>
>> In the discussion we encountered the issue of not having yet a
>> policy/strategy for implementing .2 properties which means properties
>> related to properties.
>>
>> We have one of them in CRMarchaeo:
>>
>> *AP13.2 justified by (is justification of)*
>>
>>
>>
>> Domain:*AP13* has stratigraphic relation to
>>
>> Range:   *AP11* has physical relation to
>>
>>
>>
>> Scope note:   This property identifies the type of physical
>> relation that was used to justify the type  of stratigraphic relation
>> assigned to the relation between two A5
>> 
>> Stratigraphic Modification events. Physical relations of “above” or “fills”
>> may justify the stratigraphic relation type “after”. Figure 7 gives a
>> graphical representation and Figure 6 shows an example.
>>
>>
>>
>>
>>
>> I would ask to either create a new issue for the implementation of .2
>> properties or include the discussion in the existing issue 588 as the
>> strategy should be the same for .1 and .2 .
>>
>> Whatever you think appropriate.
>>
>>
>>
>> Kind regards,
>>
>> Gerald
>>
>>
>>
>> *From: *Crm-sig  on behalf of Pavlos
>> Fafalios via Crm-sig 
>> *Reply to: *Pavlos Fafalios 
>> *Date: *Thursday, 1. December 2022 at 17:46
>> *To: *crm-sig 
>> *Subject: *Re: [Crm-sig] ISSUE 588 Implementing the .1 Properties of
>> Base and Extensions in RDF
>>
>>
>>
>> Dear all,
>>
>>
>>
>> Please find my revised homework for issue 588
>> 
>> below:
>>
>>
>> https://drive.google.com/drive/folders/1b0wW70xo2wjxNlWHYDRl7nr-fzYXTchN?usp=share_link
>>
>>
>>
>> Feel free to add your comments or send your feedback!
>>
>>
>>
>> Best regards,
>>
>> Pavlos
>>
>>
>>
>> On Tue, Sep 13, 2022 at 11:23 AM Pavlos Fafalios 
>> wrote:
>>
>> Dear Mark, all,
>>
>>
>>
>> I agree, we need to make clear which constructs of the RDF are not part
>> of CIDOC-CRM (especially since they make use of the same namespace).
>>
>> One way is to add a note in the beginning of the file. Another way would
>> be to provide them through a different namespace (not sure if this is a
>> good solution--needs some thinking).
>>
>>
>>
>> This is also a good reason for having them in a different RDF file:  all
>> classes and properties in this file, except the .1 properties, are not part
>> of CIDOC-CRM, while the .1 properties have a 'domain' class that is also
>> not part of CIDOC-CRM.
>>
>>
>>
>> Best,
>>
>> Pavlos
>>
>>
>>
>> On Mon, Sep 12, 2022 at 5:53 PM Mark Fichtner 
>> wrote:
>>
>> Dear all,
>>
>>
>>
>> nice work, thanks! I think for RDF 

Re: [Crm-sig] ISSUE Implementing .2 Properties in RDF

[Pavlos Fafalios via Crm-sig]

Dear Gerald, all,

I think we can follow the same reification approach as we do for the .1
properties.
In this case, we just need to provide the property classes of the domain
and range properties of AP13.2, i.e.:
PC_AP13_has_stratigraphic_relation_to
and
PC_AP11_has_physical_relation_to

Then, here is a (draft) example of RDF triples that make use of these
constructs:

***

   a   .

   a   .


 .

   a  ;
 ;
 .


 .

   a  ;
 ;
 .


  
***

But there are also other approaches for implementing this, such as using
named graphs, or the standard RDF reification method (i.e. using
rdf:subject, rdf:object, etc.), or RDF-start (I think).

Please correct me if I have misunderstood something!

Best regards,
Pavlos

On Mon, Apr 24, 2023 at 3:38 PM Hiebel, Gerald via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear all,
>
> we discussed CRMarchaeo and are going to make a proposel for a new version
> in the next CRM-SIG.
>
>
>
> In the discussion we encountered the issue of not having yet a
> policy/strategy for implementing .2 properties which means properties
> related to properties.
>
> We have one of them in CRMarchaeo:
>
> *AP13.2 justified by (is justification of)*
>
>
>
> Domain:*AP13* has stratigraphic relation to
>
> Range:   *AP11* has physical relation to
>
>
>
> Scope note:   This property identifies the type of physical
> relation that was used to justify the type  of stratigraphic relation
> assigned to the relation between two A5
> 
> Stratigraphic Modification events. Physical relations of “above” or “fills”
> may justify the stratigraphic relation type “after”. Figure 7 gives a
> graphical representation and Figure 6 shows an example.
>
>
>
>
>
> I would ask to either create a new issue for the implementation of .2
> properties or include the discussion in the existing issue 588 as the
> strategy should be the same for .1 and .2 .
>
> Whatever you think appropriate.
>
>
>
> Kind regards,
>
> Gerald
>
>
>
> *From: *Crm-sig  on behalf of Pavlos
> Fafalios via Crm-sig 
> *Reply to: *Pavlos Fafalios 
> *Date: *Thursday, 1. December 2022 at 17:46
> *To: *crm-sig 
> *Subject: *Re: [Crm-sig] ISSUE 588 Implementing the .1 Properties of Base
> and Extensions in RDF
>
>
>
> Dear all,
>
>
>
> Please find my revised homework for issue 588
> 
> below:
>
>
> https://drive.google.com/drive/folders/1b0wW70xo2wjxNlWHYDRl7nr-fzYXTchN?usp=share_link
>
>
>
> Feel free to add your comments or send your feedback!
>
>
>
> Best regards,
>
> Pavlos
>
>
>
> On Tue, Sep 13, 2022 at 11:23 AM Pavlos Fafalios 
> wrote:
>
> Dear Mark, all,
>
>
>
> I agree, we need to make clear which constructs of the RDF are not part of
> CIDOC-CRM (especially since they make use of the same namespace).
>
> One way is to add a note in the beginning of the file. Another way would
> be to provide them through a different namespace (not sure if this is a
> good solution--needs some thinking).
>
>
>
> This is also a good reason for having them in a different RDF file:  all
> classes and properties in this file, except the .1 properties, are not part
> of CIDOC-CRM, while the .1 properties have a 'domain' class that is also
> not part of CIDOC-CRM.
>
>
>
> Best,
>
> Pavlos
>
>
>
> On Mon, Sep 12, 2022 at 5:53 PM Mark Fichtner 
> wrote:
>
> Dear all,
>
>
>
> nice work, thanks! I think for RDF this is a valid representation,
> although I am not very happy to add properties that are not in the cidoc
> crm directly and that are not part of the language itself (like in this
> case crm:P03_reifies). As a user/reader of the rdf it is simply hard to
> understand what is part of the cidoc crm itself and what comes due to
> "workarounds". Even in as a new ontology/file/addon it mixes cidoc crm and
> non-cidoc crm things.
>
>
>
> Also we have a reification concept (E13 Attribute Assignment), I am not
> sure if we need even more of these.
>
>
>
> I'm looking forward to the discussion!
>
>
>
> Best,
>
>
>
> Mark Fichtner
>
>
>
> Germanisches Nationalmuseum
>
>
>
> Am Mo., 12. Sept. 2022 um 14:22 Uhr schrieb Pavlos Fafalios via Crm-sig <
> crm-sig@ics.forth.gr>:
>
> Dear all,
>
>
>
> Please find my homework for issue 588
> 
> in the below link (as well as in the issues' folder):
>
>
>
>
> https://docs.google.com/document/d/1oQRkmMUgyOeDsn3ZbPuQ__VtbigS9DVsHjmOtvx16uo/edit?usp=sharing
>
>
>
> Apologies for the delay! Feel free to add your comments or send your
> feedback!
>
>
> Best regards,
>
> Pavlos
>
>
>
>
> --
>
> Pavlos Fafalios
>
>