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
<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:
***********************************************************
<PC_AP13_has_stratigraphic_relation_to>
a <PC0_Typed_CRM_Property> .
<PC_AP11_has_physical_relation_to>
a <PC0_Typed_CRM_Property> .
<subject1>
<AP13_has_stratigraphic_relation_to> <object_1> .
<pc_ap13_instance>
a <PC_AP13_has_stratigraphic_relation_to> ;
<P01_has_domain> <subject1> ;
<P02_has_range> <object1> .
<subject2>
<AP11_has_physical_relation_to> <object_2> .
<pc_ap11_instance>
a <PC_AP11_has_physical_relation_to > ;
<P01_has_domain> <subject2> ;
<P02_has_range> <object2> .
<pc_ap13_instance>
<AP13.2 justified by> <pc_ap11_instance>
***********************************************************
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
<https://docs.google.com/document/d/1mKPhci0Bs0b_b4DxlhlisFgWti2Zl4nCQvQqspRQSAk/edit#heading=h.2afmg28>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 <crm-sig-boun...@ics.forth.gr> on behalf of
Pavlos Fafalios via Crm-sig <crm-sig@ics.forth.gr>
*Reply to: *Pavlos Fafalios <fafal...@ics.forth.gr>
*Date: *Thursday, 1. December 2022 at 17:46
*To: *crm-sig <crm-sig@ics.forth.gr>
*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
<https://cidoc-crm.org/Issue/ID-588-common-policy-method-for-implementing-the-.1-properties-of-base-and-extensions-in-rdf>
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
<fafal...@ics.forth.gr> 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
<m.ficht...@wiss-ki.eu> 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
<https://cidoc-crm.org/Issue/ID-588-common-policy-method-for-implementing-the-.1-properties-of-base-and-extensions-in-rdf>
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
Postdoctoral researcher (Marie Curie IF - Project
ReKnow <https://reknow.ics.forth.gr/>)
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
--
Pavlos Fafalios
Postdoctoral researcher (Marie Curie IF - Project ReKnow
<https://reknow.ics.forth.gr/>)
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
--
Pavlos Fafalios
Postdoctoral researcher (Marie Curie IF - Project ReKnow
<https://reknow.ics.forth.gr/>)
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
--
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
--
George Bruseker, PhD
Chief Executive Officer
Takin.solutions Ltd.
https://www.takin.solutions/
_______________________________________________
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
