from:"\"Martin Doerr\""

hen 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



--

 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


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 a

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

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

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

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

:p

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

2023-05-10 Thread 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

2023-05-11 Thread 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 
<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 
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 imp

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

2023-05-11 Thread 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 <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.

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

2023-05-11 Thread 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 th

Re: [Crm-sig] Issue 625: O13 triggers scope note [HW reminder]

2023-05-12 Thread Martin Doerr via Crm-sig

On 5/12/2023 7:53 AM, Wolfgang Schmidle wrote:

Dear Martin,

Thank you for your explanations, and sorry that I cannot join the discussion of
this issue today.
I think my point was that your formalisation is for "directly triggered", whereas the flood example
suggests that "triggered" can also be used in the sense of "eventually triggered". Like
the movements of the first and last ball in Newton's cradle, where there is no spatiotemporal overlap between
the triggering and triggered event (and also no change of the kind of processes, and if there is sustained
tension in this target system then virtually any system is in sustained tension). But of course Newton's
cradle is a somewhat theoretical example, and if it is obvious to any expert that the flood example fits the
scope note then so be it.

Hi Wolfgang,

You are welcome! Of course, the distinction between "triggers" and a
more general causal chain is a bit tricky. Note however, that the flood
waters (I assume) have penetrated into the library, as such, from a
forensic point of view, substance of the triggering event is directly
involved in the effect. In that sense, it is not as indirect as your
example above. Landslides, structures breaking and other sudden events,
on the other side, may in principle start without a trigger, just by
gradually passing over the threshhold of stability by continued
environmental impacts.

Nothing is obvious: Each model is an answer to a question, and there are
no models without questions.

Taking the point of view that CRMsci is still at a level of information
integration and cross-resource search, I take the implicit questions to
be to understand risks, quantitatively, and to understand effects of
such kinds of events. Possibly also, connecting an individual object to
its presence at a certain time and place in the past, for whatever
related reasoning. Conservation experts please critisize my view here!
For this purpose, the level of detail I have defended would be adequate.

If you want to make a model of the process details from the flood water
entering a building until the effects on the books, one would first
select the material with the above questions, ask for detailed analyses
as they may exist, and then enter another research process locally with
different models and tools, going into physical-chemical-biological
interactions. At least, this is how I perceive the research worklfow.

Typical triggering is, of course, pressing the button of a camera, etc.
substantial for interacting with mechanical and electronic devices. A
delay detonator may put a longer time between the final effect and the
starting of the device, but the device ticking can be regarded as part
of the triggered process.

All the best,

Martin

Best,
Wolfgang

Am 30.04.2023 um 17:56 schrieb Martin Doerr via Crm-sig :

Dear Wolfgang,

Your questions well-taken, but please do not seek a logical surrogate of
reality. It does not exist. The logic can be not more than an overlay,
approximating and simplifying reality, in more detail:

On 4/21/2023 1:59 PM, Wolfgang Schmidle via Crm-sig wrote:
Here's a diff:

* label:
OLD O13 triggers (is triggered by)
NEW O13 triggered (was triggered by)
(in the examples it was already called "triggered" rather than "triggers")

* FOL:
O13(x,y) ⇒ P182(x,y) removed

(Domain, range, quantification, examples are unchanged)

About the changes:

[Crm-sig] NEW ISSUE: Statements about Statements.

2023-05-14 Thread Martin Doerr via Crm-sig


Dear Dominic, all,

Yes, I will always defend that modeling is technology independent, 
limited however to the degree that science and technology should at 
least provide the prospect of implementation in the near future, and 
some viable approximations immediately. We definitely started the CRM 
before the technology was generally available but expected. The primary 
criterion is that the model reflects our insight about the scientific 
discourse we target at. As such, I see the model-level discussion to be 
between reasoning about "proposition sets" versus a "single binary 
proposition". The technical discussion should be about best and most 
effective approximations, regardless popular or not. The effectiveness 
will depend on use cases and platform requirements.


Please let us know, who is interested in participating in a narrower 
subgroup for creating  a document analyzing the alternatives.


Best,

Martin

On 5/11/2023 8:01 PM, Dominic Oldman wrote:

Hi

Just a quick question on this. We develop the model independently of 
technology. I can see that this discussion is getting technical. I 
currently implement propositions sets using RDF named graphs because 
we can and it works but it is not stipulated. Rob suggests that there 
are tech upgrades that might suit this issue better. However, isn't it 
the case that we need to be able to implement in different ways (I 
don't currently know much about RDF*) depending on the systems we 
have? How is RDF* implemented? - is it backwardly compatible with what 
we are all using? Do we give more modelling credence to things that 
everyone uses? etc., etc. But aren't these questions the reason why we 
are technology independent?  Given this, my question is, - have we got 
to a stage when the modelling now depends on a particular technology?  
Can someone provide some clarification on this? Which solution is tech 
independent? Are they all independent of this tech discussion? One is 
at least.


D

On Thu, 11 May 2023 at 16:18, Martin Doerr via Crm-sig 
 wrote:


Dear Robert,

We have just created the new issue to discuss this in detail. We
should prepare a detailed analysis, citing all pros and cons. May
be we continue this discussion better in a subgroup?

Named Graphs are not a very specific technology, if we take the
fact that all current triple stores are actually implemented as
quad stores, regardless whether they call the construct "Named
Graph" or "context". We have used and implemented this feature,
and it is very performant. It runs on BlazeGraph as well. I think
their is not a simple answer to that. Performance can become a
major issue, when you have really a lot of data.

For the attribution of artists and "style of" vs "school of" etc.
of the collection management system of the British Museum, the
ResearchSpace Project had created a set of subproperties of P14
carried out by, which could be used as input for a roles vocabulary.

I did not propose to use Dig as is, but to consider the construct.
The W3C annotation model is very interesting. We would need a
connection to the Creation Event of making an annotation, and
whose opinion it is, in order to make it CRM compatible. Why not
allowing a Named Graph as target?  We should compare the segment
construct of the W3C annotation model with the METS  types
and extensions we used. The Dig model was used to trace provenance
of annotated area through transformations of digital objects. That
was very important for exchanging research insights on 3D models.
To be discussed!

 We can extend E13 to Proposition Sets, which would be very
important to describe consistently CRMinf and generalized
observations. That would then be most effectively implementd via
Named Graphs.

Opinions?

Best,

Martin

On 5/11/2023 3:41 PM, Robert Sanderson wrote:


If the intent is that the assertion is in the discourse, and not
a syntactic workaround for .1 properties that would be
unnecessary if we had RDF* or property graphs, then I would say
E13 is exactly the right approach to use. In comparison, I
consider the PC classes to be just that - a syntactic work around
needed in RDF and not part of the discourse. In LInked Art, in a
discussion around uncertain attribution of artists and "style of"
vs "school of", 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 h

Re: [Crm-sig] NEW ISSUE: Statements about Statements.

2023-05-15 Thread Martin Doerr via Crm-sig


You are all welcome!

I'll send you soon an outline of what I have in mind.

All the best,

Martin

n 5/14/2023 10:55 PM, Dominic Oldman wrote:

Hi Martin,

I would like to be involved.

Thanks,

Dominic



On Sun, 14 May 2023 at 19:34, Martin Doerr  wrote:

Dear Dominic, all,

Yes, I will always defend that modeling is technology independent,
limited however to the degree that science and technology should
at least provide the prospect of implementation in the near
future, and some viable approximations immediately. We definitely
started the CRM before the technology was generally available but
expected. The primary criterion is that the model reflects our
insight about the scientific discourse we target at. As such, I
see the model-level discussion to be between reasoning about
"proposition sets" versus a "single binary proposition". The
technical discussion should be about best and most effective
approximations, regardless popular or not. The effectiveness will
depend on use cases and platform requirements.

Please let us know, who is interested in participating in a
narrower subgroup for creating  a document analyzing the alternatives.

Best,

Martin

On 5/11/2023 8:01 PM, Dominic Oldman wrote:

Hi

Just a quick question on this. We develop the model independently
of technology. I can see that this discussion is getting
technical. I currently implement propositions sets using RDF
named graphs because we can and it works but it is
not stipulated. Rob suggests that there are tech upgrades that
might suit this issue better. However, isn't it the case that we
need to be able to implement in different ways (I don't currently
know much about RDF*) depending on the systems we have? How is
RDF* implemented? - is it backwardly compatible with what we are
all using? Do we give more modelling credence to things that
everyone uses? etc., etc. But aren't these questions the reason
why we are technology independent?  Given this, my question is, -
have we got to a stage when the modelling now depends on a
particular technology? Can someone provide some clarification on
this? Which solution is tech independent? Are they all
independent of this tech discussion? One is at least.

    D

    On Thu, 11 May 2023 at 16:18, Martin Doerr via Crm-sig
 wrote:

Dear Robert,

We have just created the new issue to discuss this in detail.
We should prepare a detailed analysis, citing all pros and
cons. May be we continue this discussion better in a subgroup?

Named Graphs are not a very specific technology, if we take
the fact that all current triple stores are actually
implemented as quad stores, regardless whether they call the
construct "Named Graph" or "context". We have used and
implemented this feature, and it is very performant. It runs
on BlazeGraph as well. I think their is not a simple answer
to that. Performance can become a major issue, when you have
really a lot of data.

For the attribution of artists and "style of" vs "school of"
etc. of the collection management system of the British
Museum, the ResearchSpace Project had created a set of
subproperties of P14 carried out by, which could be used as
input for a roles vocabulary.

I did not propose to use Dig as is, but to consider the
construct. The W3C annotation model is very interesting. We
would need a connection to the Creation Event of making an
annotation, and whose opinion it is, in order to make it CRM
compatible. Why not allowing a Named Graph as target?  We
should compare the segment construct of the W3C annotation
model with the METS  types and extensions we used. The
Dig model was used to trace provenance of annotated area
through transformations of digital objects. That was very
important for exchanging research insights on 3D models. To
be discussed!

 We can extend E13 to Proposition Sets, which would be very
important to describe consistently CRMinf and generalized
observations. That would then be most effectively implementd
via Named Graphs.

Opinions?

Best,

Martin

On 5/11/2023 3:41 PM, Robert Sanderson wrote:


If the intent is that the assertion is in the discourse, and
not a syntactic workaround for .1 properties that would be
unnecessary if we had RDF* or property graphs, then I would
say E13 is exactly the right approach to use. In comparison,
I consider the PC classes to be just that - a syntactic work
around needed in RDF and not part of the discourse. In
LInked Art, in a discuss

Re: [Crm-sig] NEW ISSUE: Statements about Statements.

2023-05-18 Thread Martin Doerr via Crm-sig


Dear All,

I have noted all your declarations of interest in this discussion! Next 
week, I'll set up an initial google document open to all members of this 
mailing list. I'll keep the discussions to those interested until we 
have a basic agreement about the document.


See also: 
https://enterprise-knowledge.com/rdf-what-is-it-and-why-do-i-need-it/


best,

Martin

--

 Dr. Martin Doerr
  
 Honorary Head of the

 Center for Cultural Informatics
 
 Information Systems Laboratory

 Institute of Computer Science
 Foundation for Research and Technology - Hellas (FORTH)
  
 N.Plastira 100, Vassilika Vouton,

 GR70013 Heraklion,Crete,Greece
 
 Vox:+30(2810)391625

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

[Crm-sig] CRM applications

2023-05-19 Thread Martin Doerr via Crm-sig

Dear All,

These excellent implementations have not become so widely known:

Eero Hyvönen: *How to Create a National Cross-domain Ontology and Linked
Data Infrastructure and Use It on the Semantic Web
<https://seco.cs.aalto.fi/publications/2022/hyvonen-infra-2022.pdf>*.
2023. Semantic Webjournal,forth-coming, . bib
<https://seco.cs.aalto.fi/publications/2022/hyvonen-infra-2022.bib>pdf
<https://seco.cs.aalto.fi/publications/2022/hyvonen-infra-2022.pdf>link
<http://www.semantic-web-journal.net/content/how-create-and-use-national-cross-domain-ontology-and-data-infrastructure-semantic-web>

Eero Hyvönen: *Digital Humanities on the Semantic Web: Sampo Model and
Portal Series
<https://seco.cs.aalto.fi/publications/2021/hyvonen-sampo-model-2021.pdf>*.
Semantic Webjournal, vol. 14, no. 4, pp. 729-744, IOS Press, 2023. bib
<https://seco.cs.aalto.fi/publications/2021/hyvonen-sampo-model-2021.bib>pdf
<https://seco.cs.aalto.fi/publications/2021/hyvonen-sampo-model-2021.pdf>link
<https://doi.org/10.3233/SW-223034>

Many of the "Sampos" use CIDOC CRM -based data models.

All the best,

Martin

Dr. Martin Doerr

Honorary Head of the

Center for Cultural Informatics

Information Systems Laboratory

Institute of Computer Science
Foundation for Research and Technology - Hellas (FORTH)

N.Plastira 100, Vassilika Vouton,

GR70013 Heraklion,Crete,Greece

Vox:+30(2810)391625
Email: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] E-VOTE: LRMoo R10 is member of (has member)

2023-08-01 Thread Martin Doerr via Crm-sig


YES!

Martin

On 7/13/2023 1:20 AM, Pat Riva via Crm-sig wrote:

Hello all,

I am calling for an e-vote relating to LRMoo. Please vote on the list 
by *July 26th*.


Background: At the end of SIG meeting #55 in May 2023 in Heraklion, 
the LRMoo WG presented a sketch of a new approach to R10 after the 
proposal made at the meeting 
<https://docs.google.com/document/d/1UlVMIea5BHoFd8SJGaTNUvC64YpyGFmyahRO0VBkT5U/edit> 
was considered insufficient. This was received with interest but there 
was not time to discuss a full proposal.


*This e-vote is to approve the redefinition of R10, and the 
consequences on R67 (which was originally a subproperty of R10).*


Please see the proposed new text in this Google doc (E-vote: R10 
<https://docs.google.com/document/d/1yOHjkIo_FW1_x85zYNJbaOrGT3PRizjxcn4ZGPjLuQI/edit>).


Thanks,
Pat

Pat Riva

Interim University Librarian / Bibliothécaire en chef par intérim

Concordia University / Université Concordia

1455 de Maisonneuve West, LB-331

Montréal, Québec H3G 1M8

Canada

pat.r...@concordia.ca <mailto:pat.r...@concordia.ca>


___
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] Issue 615 (scope note of E13 Attribute Assignment)

2023-08-23 Thread Martin Doerr via Crm-sig


Dear All,

I propose to *close* issue 615 by e-vote. The new text for E13 Attribute 
assignment has been approved already.  Trailing an issue into another 
entity is not good practice, but to answer the question:


*As a rule*, multiple properties of a superclass should not be 
specialized altogether by analogy. Properties are and must be 
specialized *if and* *only if* they convey a more specific meaning than 
the superproperty of the superclass in the context of the subclass. 
Obviously, there is nothing you can say about an entity that enables it 
to have an Identifier assigned and not only an Appellation. Conversely, 
there should exist at least one entity that, by its nature, cannot be 
assigned an identifier to.


This rule, even though general KR, may be worthwhile to be documented as 
another *ISSUE*. We had more frequently cases in CRM extensions, were 
properties were not specialized but should have been.


Best,

Martin

On 8/18/2023 12:00 AM, Eleni Tsouloucha wrote:


Dear all,


Back in Luxembourg, the SIG pondered on the lack of subproperty for 
P140 assigned attribute tothat is specific to E15 Identifier 
Assignment(unlike the situation with P141 assigned, for which there 
exists a subproperty that is particular to E15, namely P37 assigned) 
and did not conclude as to what had motivated this decision.



At the time we had said that all relevant discussions would continue 
in the thread for issue 615 
<https://cidoc-crm.org/Issue/ID-615-scope-note-of-e13-attribute-assignment>, 
but we have not formally assigned anyone to do the HW. Would you be 
interested? If yes, is it something that you feel can be done in time 
for the next SIG meeting?


Either way, please let me know by 1 September.


All the best,


--
Eleni Tsouloucha
Philologist - MA Linguistics & Language Technologies
Center for Cultural Informatics
Information Systems Laboratory - Institute of Computer Science
Foundation for Research and Technology - Hellas (FORTH)

Address: N. Plastira 100, GR-70013 Heraklion, Grece
email: tsoulo...@isc.forth.gr, eleni.crm@gmail.com
Tel: +30 2810391488



--

 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

[Crm-sig] HW Issue 630: redraft the scope note of P38 deassigned

2023-09-02 Thread Martin Doerr via Crm-sig



   Dear All,

   Here my proposal:

   OLD:

   P38 deassigned (was deassigned by)

   Domain:

   E15 <#m_2848461322383461192__toc7601> Identifier Assignment

   Range:

   E42 <#m_2848461322383461192__toc8076> Identifier

   Subproperty of:

   E13 <#m_2848461322383461192__toc7561> Attribute Assignment. P141
   <#m_2848461322383461192__toc11036> assigned (was assigned by): E1
   <#m_2848461322383461192__toc7281> CRM Entity

   Quantification:

   many to many (0,n:0,n)

   Scope Note:

   This property records the identifier that was deassigned from an
   instance of E1 CRM Entity.

   De-assignment of an identifier may be necessary when an item is
   taken out of an inventory, a new numbering system is introduced or
   items are merged or split up.

   The same identifier may be deassigned on more than one occasion.

   Examples:

  The identifier assignment on 31st July 2001 of the silver cup
   OXCMS:2001.1.32 (E15) deassigned “232” (E42). (fictitious)

   NEW

   P38 deassigned (was deassigned by)

   Domain:

   E15 <#m_2848461322383461192__toc7601> Identifier Assignment

   Range:

   E42 <#m_2848461322383461192__toc8076> Identifier

   Subproperty of:

   E13 <#m_2848461322383461192__toc7561> Attribute Assignment. P141
   <#m_2848461322383461192__toc11036> assigned (was assigned by): E1
   <#m_2848461322383461192__toc7281> CRM Entity

   Quantification:

   many to many (0,n:0,n)

   Scope Note:

   This property associates an instance of E42 Identifier that was
   deassigned from an instance of E1 CRM Entity by an instance of E15
   Identifier Assignment.

   De-assignment of an identifier means that the actor, typically an
   organisation, carrying out the respective instance of E15 Identifier
   Assignment, has decided no more to use the respective identifier for
   an item which has been in its possession or was referred to in a
   context under the actor’s control. Reasons to do so may be, besides
   others, when an item is taken out of an inventory, items are merged
   or split up in a collection, an object is acquired under reference
   to the identifier of the giving institution or a new numbering
   system is introduced. Depending on such cases, de-assignment may be
   associated with the assignment of a new identifier (P37 assigned
   (was assigned by)) in the same instance of E15 Identifier Assignment.

   The same identifier may be deassigned on more than one occasion.

   Examples:

  The identifier assignment on 31st July 2001 of the silver cup
   OXCMS:2001.1.32 (E15) deassigned “232” (E42). (fictitious)

 

   Improvements?

   Best,

   Martin



--

 Dr. Martin Doerr
  
 Honorary Head of the

 Center for Cultural Informatics
 
 Information Systems Laboratory

 Institute of Computer Science
 Foundation for Research and Technology - Hellas (FORTH)
  
 N.Plastira 100, Vassilika Vouton,

 GR70013 Heraklion,Crete,Greece
 
 Vox:+30(2810)391625
 Email: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

[Crm-sig] HW issue 556

2023-09-05 Thread Martin Doerr via Crm-sig


Dear All,

Some years ago we analyzed place types from different gazetteers, with 
the focus on  such phenomena with a relevantspatiotemporal evolution:


I have made the following distinctions by abstracting from the 
Alexandria Gazetteer place types, according to the kind of phenomena 
that are responsible for their definition and identity and for avoiding 
possible polysemy of the same term/name. Similar place types appear in 
the TGN. Place types in Geonames should also be considered. An early 
version of place types from the INSPIRE standard appeared not to be as good.


   A)Distinct spaces defined by geomorphological forms (continents,
   islands, mountain ranges, water bodies, vulcanos)

   B)Distinct habitats defined by life form (kinds of vegetation etc.)

   C)Coherent, evolving human-maintained spaces (settlements, roads,
   areas formed by agriculture or other exploiation)

   D)Spaces defined by inhabitation/stay of a specific cultural group
   of people (town population, tribe, language group)

   E)Areas determined by execution of political power (Nation, country,
   administrative unit, protection zone)

   F)Possibly evolving areas defined by theoretical declaration
   motivated by scientific, social or political interests.

Wheras A), F) may characterize just spacetime volumes, B) through E) may 
characterize E4 Periods in the narrower sense.


It seems that only very few high-level abstractions are necessary to 
make a term like "Greece" or "Rome" unambiguous. Therefore the above may 
lead to a minimal vocabulary recommended by the CRM for E4 Period and 
Spacetime Volume


I attach the Alexandria terms.

Best,

Martin

--
--------
 Dr. Martin Doerr
  
 Honorary Head of the

 Center for Cultural Informatics
 
 Information Systems Laboratory

 Institute of Computer Science
 Foundation for Research and Technology - Hellas (FORTH)
  
 N.Plastira 100, Vassilika Vouton,

 GR70013 Heraklion,Crete,Greece
 
 Vox:+30(2810)391625
 Email:mar...@ics.forth.gr   
 Web-site:http://www.ics.forth.gr/isl


alexandria gazetteer.xlsx
Description: MS-Excel 2007 spreadsheet
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

[Crm-sig] New Issue (if not hidden in 645): Content of Proposition Set

2023-09-10 Thread Martin Doerr via Crm-sig


Dear All,

I suggest to discuss the meaning of I4 Proposition Set, also related to 
issue 550, 510, 610


Two problems:

A) the content model. If we follow the *logic of P190*, an I4 
Proposition Set should be represented by a URI and a content model, 
which could be implemented as Named Graph in a KB.
If we take an I4 as a Propositional Object, we would still need a 
symbolic form, which would need a representative copy (or P190).


B) If we take an I4 as *fitting  potentially the reality* under 
discourse, or only as a "possible world" being discussed, we need to 
clarify this role. Using I2 Belief, we relate the Proposition Set to be 
"true" or "false". We need to clarify, if "true" means "real", if the 
propositions can be related to reality. Similarly, we need to clarify, 
if an I11 Situation, as a special case, is meant to be discussed as 
statements only, or, if "observed", to *exist *in reality. We need to 
interpret the link to an observation is implying its reality or not.
This is particularly interesting if we observe an area and state it does 
NOT contain X.


C) We should clarify how we may refer to Proposition Sets with a human 
readable text, rather than a CRM compatible RDF model.


Best,

Martin

--

 Dr. Martin Doerr
  
 Honorary Head of the

 Center for Cultural Informatics
 
 Information Systems Laboratory

 Institute of Computer Science
 Foundation for Research and Technology - Hellas (FORTH)
  
 N.Plastira 100, Vassilika Vouton,

 GR70013 Heraklion,Crete,Greece
 
 Vox:+30(2810)391625
 Email: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] Issue 579 (how to model the focus or view of an observation)

2023-09-11 Thread Martin Doerr via Crm-sig

Dear Thanasi, all,

I think modeling a view direction is an overspecialization. I now
believe for purposes of information integration, the question is to
describe an area covered by an observation. specific directions etc.
should be placed in an extended description. The more general question
to specify an observed area, as in archaeological surveys, needs to be
modeled indeed. This is neither an observed situation, nor a measurement
of dimensions. Also, we need to understand which kinds of observation
pertain to areas (typically optical, radar).

This should be discussed!

Best,

Martin

On 8/18/2023 12:00 AM, Eleni Tsouloucha wrote:

Dear Martin, all,

According to the decision of the 53rd SIG meeting (May 2022), issue
579
<https://cidoc-crm.org/Issue/ID-579-new-issue-how-to-model-the-focus-or-view-of-an-observation>was
on hold until we had resolved 583
<https://cidoc-crm.org/Issue/ID-583-how-to-assign-dimensions-to-relative-positions-to-distances-in-space-time-and-other>(theorizing
about dimensions of spatiotemporal distances btw instances of S15
Observable Entity).

Now that 583 is done and the new classes & properties have been
introduced in CRMsci (V2.1), do we go back to this issue?

Are you interested in reviving it in time for the next SIG meeting? If
you don’t have anything to report by then but are still interested in
pursuing this line of work it’s still OK, maybe we could freshen
everyone’s memory and then ask for volunteers to work on it.

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

[Crm-sig] Issue 635 (property quantifier mismatches) and P191

2023-09-13 Thread Martin Doerr via Crm-sig


Dear All,

Regarding as last item of issue 635 the property /P191 had duration://
/
Issue 559 was resolved as:

"In case the instance of S15 Observable Entity is more specifically an 
instance of E18 Physical Thing, using the property O12 has dimension (is 
dimension of) is equivalent to using the property P43 has dimension (is 
dimension of). In other words, using the one implies the other."


Sadly, P43 has quantification"one to many, dependent (0,n:1,1)", but we 
use O12 now for relative dimensions between multiple things  in CRMsci, 
AND we use Dimension in /P191 had duration (was duration of)/ from a 
Timespan, which is not an instance of E70 Thing, with quantification 
"one to one (1,1:1,1) ". Note that P191 is NOT a subproperty of P43, but 
E54 Dimension pertains to both.


It appears to me that P43 should have quantification"many to many 
(0,n:0,n)" ,

and P191 should have quantification"one to one (1,1:0,1)" ,

but this leaves P43 without the important semantics of dependency.

Taking relative dimensions into account, it should be clarified that an 
instance of E54 Dimension is dependent on the combination of references 
to it.

This is a task for an FOL or so, isn't it?

Otherwise, we would need to specialize E54 in CRMbase, not really nice.


Opinions?


Best,

Martin


 Forwarded Message 
Subject:Issue 635 (property quantifier mismatches)
Date:   Fri, 18 Aug 2023 00:00:00 +0300
From:   Eleni Tsouloucha 
To: 	Wolfgang Schmidle , Martin Doerr 


CC: Chryssoula Bekiari 



Dear both,


The correct property quantification for /P191 had duration/ has not been 
determined yet. Have you resolved this? If yes, should we call an evote 
or would you rather we discussed it at the SIG?


Best,

--
Eleni Tsouloucha
Philologist - MA Linguistics & Language Technologies
Center for Cultural Informatics
Information Systems Laboratory - Institute of Computer Science
Foundation for Research and Technology - Hellas (FORTH)

Address: N. Plastira 100, GR-70013 Heraklion, Grece
email: tsoulo...@isc.forth.gr, eleni.crm@gmail.com
Tel: +30 2810391488

--

 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

[Crm-sig] Issue 490: how to model a file [HW reminder]

2023-09-15 Thread Martin Doerr via Crm-sig

safeguarding the maintainers against unexpected change of content under 
this URL. If more than one representative copy is referred to, the 
maintainers should control their mutual consistency at the symbolic 
level of the object intended to be represented.


Examples:

Definition of the CIDOC Conceptual Reference Model Version 7.1.1 (E73) 
/has representative copy/ The content under 
https://cidoc-crm.org/sites/default/files/cidoc_crm_v.7.1.1_0.pdf (E25) 
on the sever of ICS-FORTH in Heraklion, Greece.


[The edition 7.1.1 of the CIDOC CRM is registered under the public URI 
"https://doi.org/10.26225/FDZH-X261";, 
<https://cidoc-crm.org/sites/default/files/cidoc_crm_v.7.1.1_0.pdf>which 
redirects users to the representative copy under 
https://cidoc-crm.org/sites/default/files/cidoc_crm_v.7.1.1_0.pdf. 
<https://cidoc-crm.org/sites/default/files/cidoc_crm_v.7.1.1_0.pdf>ICS-FORTH 
as organisation is responsible for the persistence of this content under 
the respective URL to the DOI Foundation]


-

*Note *that the MS Word copy AND the pdf copy of the CRM is regarded to 
be copies of an *identical symbolic content, *the one we are interested in!

A *vocabulary of symbolic levels *is still to be defined!

IF an instance of *E73 Information Object *is referred to in a KB via *a 
(persistent) URL*, I would regard this as a compression of URI - Pxxx - 
URL. This practice would not allow for the distinction between bitwise 
identity or higher symbolic form.


Partners of this homework please comment if I have missed something!

Best,

Martin





 Forwarded Message 
Subject:    Re: Issue 490: how to model a file [HW reminder]
Date:   Thu, 31 Aug 2023 18:35:38 +0300
From:   Martin Doerr 
To: thana...@softicon.co.uk
CC: 	George Bruseker , Christian Emil Ore 





On 8/30/2023 5:17 PM, Athanasios Velios wrote:

Dear Martin,

Of course, I should have thought that the collective physical features 
in different machines can have one identity. It makes sense.


I think part of the revised scope note might fit better in the RDF 
guidelines document, but I understand how it would work.


Did you mean to copy George and CEO in your last email?

YES!😁


All the best,

Thanasis

On 29/08/2023 16:55, Martin Doerr wrote:

Dear Thanasi,

Yes, we need to adjust the scope note. My opinion about cloud 
services is that:


They use a finite set of dedicated machines at any time with distinct 
ownership. They have one master controller. There are no unregistered 
copies possibly lingering about. All that does not affect the 
materiality of the set of copies. They have an internal integrity 
algorithm. The Human-Made Feature is the total of tracks employed. 
This is fixed at any point in time algorithmically. We do not model 
the internals of the cloud service, nor do we have access to it. For 
us, ontologically, it does not matter how they work internally. They 
are prone to material failure altogether. Reduced likelihoods does 
not make it immaterial.


It reminds me the RAID machine installation at the GNM in Nuremberg. 
They automatically saved on two machines, and gave a reliability of 
20.000 years. After 6 months, an air condition failure caused the 
crash of the whole system.


Would that make sense😁?

*New proposal:*

Pxxx has representative copy

Domain:

E90 Symbolic Object

Range:

E25 Human-Made Feature

Subproperty of:

E90 Symbolic Object. P128i is carried by (carries): E18 Physical Thing

Quantification:

many to many (0,n:0,n)

Scope note:

This property associates an instance of E90 Symbolic Object with a 
complete, identifying representation of its content in the form of a 
sufficiently readable instance of E25 Human-Made Feature, including, 
in particular, representations on electronic media, regardless 
whether they reside internally in clusters of electronic machines, 
such as in so-called cloud services, or on removable media.


This property only applies to instances of E73 Information Object 
that can completely be represented by discrete symbols, in contrast 
to analogue information. The representing object may be more specific 
than the symbolic level defining the identity condition of the 
represented. This depends on the type of the information object 
represented. For instance, if a text has type "Sequence of Modern 
Greek characters and punctuation marks", it may be represented in a 
formatted file with particular fonts on a particular machine, meaning 
however only the sequence of Greek letters. Any additional analogue 
elements contained in the representing object will not regarded to be 
part of the represented.


As another example, if the represented object has type "English words 
sequence", American English or British English spelling variants may 
be chosen to represent the English wor

[Crm-sig] ISSUE 614: previously (Re: New Issue (if not hidden in 645): Content of Proposition Set)

2023-09-17 Thread Martin Doerr via Crm-sig

and then

   A) Spell out the properties
  B) Adjust scope notes of I4, Observation etc.
  c) write the FOL connection between single property assignment and I4.

Best,

Martin

On 9/10/2023 9:52 PM, Martin Doerr wrote:

Dear All,

I suggest to discuss the meaning of I4 Proposition Set, also related 
to issue 550, 510, 610


Two problems:

A) the content model. If we follow the *logic of P190*, an I4 
Proposition Set should be represented by a URI and a content model, 
which could be implemented as Named Graph in a KB.
If we take an I4 as a Propositional Object, we would still need a 
symbolic form, which would need a representative copy (or P190).


B) If we take an I4 as *fitting  potentially the reality* under 
discourse, or only as a "possible world" being discussed, we need to 
clarify this role. Using I2 Belief, we relate the Proposition Set to 
be "true" or "false". We need to clarify, if "true" means "real", if 
the propositions can be related to reality. Similarly, we need to 
clarify, if an I11 Situation, as a special case, is meant to be 
discussed as statements only, or, if "observed", to *exist *in 
reality. We need to interpret the link to an observation is implying 
its reality or not.
This is particularly interesting if we observe an area and state it 
does NOT contain X.


C) We should clarify how we may refer to Proposition Sets with a human 
readable text, rather than a CRM compatible RDF model.


Best,

Martin
--

  Dr. Martin Doerr
   
  Honorary Head of the

  Center for Cultural Informatics
  
  Information Systems Laboratory

  Institute of Computer Science
  Foundation for Research and Technology - Hellas (FORTH)
   
  N.Plastira 100, Vassilika Vouton,

  GR70013 Heraklion,Crete,Greece
  
  Vox:+30(2810)391625
  Email:mar...@ics.forth.gr   
  Web-site:http://www.ics.forth.gr/isl



--

 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] Urgent: status of CRMinf, CRMsci, CRMtex, CRMdig, CRMba, CRMsoc

2023-09-24 Thread Martin Doerr via Crm-sig


Dear Christian-Emil,

To my understanding:

CRMarchaeo: major consolidation with version 7.1 finished in version 2.0 
(draft), declaration of new official version pending.
CRMinf: major revision of "belief adoption" finished, interface with 
CRMtex finished (for reading material texts), reformatting to new 
standard templates and declaration of new

   official version pending.
CRMsci: consolidation with version 7.1 finished, stable version 2.0, RDF 
available, working on observation and measurement of /relations between 
multiple objects/ (major competitive standards do not model such 
relations!).
CRMtex: consolidation with version 7.1 finished, stable version 2.0. 
Interfacing with CRMinf for citation and content interpretation.

CRMdig: review started, no news
CRMpem (digital services): review started

CRMinfluence is not yet proposed as a recommended extension. It is used 
in project work, and may become a potential part of CRMsoc or model on 
its own. Too early to report. Similarly, activity model, business 
provisions and obligations.


CRMsoc: no news. consolidation of conflicting proposals pending.

Please correct, enrich!

Best,

Martin

On 9/23/2023 11:23 PM, Christian-Emil Smith Ore via Crm-sig wrote:



Dear all,

I am compiling the crm sig report for 2023 to be presented at the 
CIDOC AGM. In the 2022 report the status of the models where described 
as shown below. I need updated information by Monday evening. For the 
models I don't get any formation about, I will just put under the 
heading  "Nothing new to report in 2023".



Also, the draft model CRMInfluence is brand new and is just a draft. 
THe largest problem is the term breaking the rule about nice and short 
names.



Best,

Christian-Emil

•General maintenance of
–CRMarcheo(stable)
–CRMinf(working on model for citations, interfacing with CRMtex)
–CRMsci(working on aspects of observation)
•Development of draft models
–CRMtex
•is widely consolidated, but still some scope notes, quantifiers etc. 
missing

–CRMdig
•reviewstarted
–CRMba
•interested teams wanted
–CRMsoc

What is the current status?


Best,

Christian-Emil


___
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

[Crm-sig] Issue: P168i defines place shortcut


Dear All,

I propose a shortcut in CRMgeo for E53 Place P189i is approximated by: 
E53 Place P168 place is defined by : E94 Space Primitive,

for obvious practical reasons. It can have the same label.

Best,

Martin

--

 Dr. Martin Doerr
  
 Honorary Head of the

 Center for Cultural Informatics
 
 Information Systems Laboratory

 Institute of Computer Science
 Foundation for Research and Technology - Hellas (FORTH)
  
 N.Plastira 100, Vassilika Vouton,

 GR70013 Heraklion,Crete,Greece
 
 Vox:+30(2810)391625
 Email: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] Διπλωματική


Here some corrections:

Zorbas:

Musical Theme better E90 Symbolic Object, has type: "Musical Theme".

Using P165 with E89 is an error. Irini, please check all properties you 
use if they are applicable😁!


Two timespans for one event is forbidden: "many to one, necessary 
(1,1:0,n)", see definition! Please learn to understand these definitions😁.


  Please comment in your work: If you see the need to assign two 
time-spans to one event, you have mistaken two distinct events for one!
      This is foundational to the CRM. Create two events, and a 
relation between them.



Delphos Gown:


  The place of the Moma: This is tricky! The P168 defines a point, the 
Moma building defines an area that can be observed. A place cannot be 
both. Please comment in your work: The space primitive defines a place, 
which is a point, which "P189 approximates" the place of the Moma 
Building. This could be simplified! (I just made a submission to crm-sig).


Sword of Goujian:

An event and a larger period cannot have the same time-span! The Event 
"falls within" the Period, is more precise than that the timespan of the 
event falls within that of the period. If you simply want to say the 
Event "falls within" the Period, you only assign a timespan to the 
Period, not the event, because this confuses your "provenance of 
knowledge", is this clear?😉, Otherwise, we discuss it in more detail, 
it is foundational to the CRM.


Cheers,


Martin

On 9/25/2023 11:45 AM, Martin Doerr wrote:

Καλησπέρα σας! Μήπως να κάνουμε άλλη τηλεδιάσκεψη τη Πέμπτη απόγευμα;

Μάρτιν

On 9/19/2023 3:03 PM, Sarantos Kapidakis wrote:
https://drive.google.com/drive/folders/1v7vtvNBIijCN6B1vknfIJqgvXEMFZy3a?usp=sharing 



On Tue, Sep 19, 2023 at 02:45:29PM +0300, Martin Doerr wrote:

Dear All,

Please send me the link to the google page with the thesis text and
examples! I have too many links, costs a lot of time to pick the 
right one

out if it is not in the message😉

Best,

Martin


On 9/19/2023 12:29 PM, ΣΑΡΑΝΤΟΣ ΚΑΠΙΔΑΚΗΣ wrote:

CIDOC examples




 



Microsoft Teams meeting
Join on your computer, mobile app or room device
Click here to join the meeting 
<https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZmY1N2QyN2ItMTU3Ny00MDhmLWEyMjAtMTVmYzBlOWQ5NWEy%40thread.v2/0?context=%7b%22Tid%22%3a%220c8943ee-c370-4bb3-ba51-321f406f32ec%22%2c%22Oid%22%3a%2248cb1937-c2dd-4336-9d51-c789c4698a66%22%7d>


Meeting ID: 338 102 176 07
Passcode: mWagBT
Download Teams
<https://www.microsoft.com/en-us/microsoft-teams/download-app> | 
Join on

the web <https://www.microsoft.com/microsoft-teams/join-a-meeting>
Learn More <https://aka.ms/JoinTeamsMeeting> | Meeting options 
<https://teams.microsoft.com/meetingOptions/?organizerId=48cb1937-c2dd-4336-9d51-c789c4698a66&tenantId=0c8943ee-c370-4bb3-ba51-321f406f32ec&threadId=19_meeting_ZmY1N2QyN2ItMTU3Ny00MDhmLWEyMjAtMTVmYzBlOWQ5NWEy@thread.v2&messageId=0&language=en-US>


 



ΣΑΡΑΝΤΟΣ ΚΑΠΙΔΑΚΗΣ has invited you to Διπλωματική
Title: Διπλωματική
Location: Microsoft Teams Meeting
When: Tuesday, September 19, 2023 7:00 PM – 8:30 PM




Organizer:
ΣΑΡΑΝΤΟΣ ΚΑΠΙΔΑΚΗΣ 
Description: CIDOC examples



 


Microsoft Teams meeting
Join on your computer, mobile app or room device
Click here to join the 
meeting<https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZmY1N2QyN2ItMTU3Ny00MDhmLWEyMjAtMTVmYzBlOWQ5NWEy%40thread.v2/0?context=%7b%22Tid%22%3a%220c8943ee-c370-4bb3-ba51-321f406f32ec%22%2c%22Oid%22%3a%2248cb1937-c2dd-4336-9d51-c789c4698a66%22%7d>

Meeting ID: 338 102 176 07
Passcode: mWagBT
Download
Teams<https://www.microsoft.com/en-us/microsoft-teams/download-app> |
Join on the
web<https://www.microsoft.com/microsoft-teams/join-a-meeting>
Learn More<https://aka.ms/JoinTeamsMeeting> | Meeting 
options<https://teams.microsoft.com/meetingOptions/?organizerId=48cb1937-c2dd-4336-9d51-c789c4698a66&tenantId=0c8943ee-c370-4bb3-ba51-321f406f32ec&threadId=19_meeting_ZmY1N2QyN2ItMTU3Ny00MDhmLWEyMjAtMTVmYzBlOWQ5NWEy@thread.v2&messageId=0&language=en-US> 

 






Attendees:

  *
 ΣΠΥΡΙΔΑΚΗ ΕΙΡΗΝΗ 
  *
 ΕΜΜΑΝΟΥΗΛ ΠΕΠΟΝΑΚΗΣ 
  *
 mar...@ics.forth.gr 






--

  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

[Crm-sig] PLease delete last message inGreek!


On 9/25/2023 12:28 PM, Martin Doerr via Crm-sig wrote:

Here some corrections:



--

 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] Issue 490: how to model a file [HW reminder]


Dear Daria,

Thank you for this message! I think we all agree with your comment, but 
sadly, people seem to forget that more and more, being blinded by the 
flood of digitally available information.


When I wrote:
"Using an archival identifier for a paper copy, a removable digital 
medium or a URL for a file on a machine, in all cases the maintainers of 
the archive must guarantee that the identifier will be uniquely 
connected with the content. Otherwise, using a URL in a KB is simply 
inadequate."


I did not want to open this discussion. For 500 years the disciples of 
Buddha relied on oral tradition by many people as being more reliable 
than the written form.


Here an anlysis we did many years ago, with an analytical model:

Petraki, M. (2005). Evaluating the reliability of system configurations 
for long term digital preservation 
<http://elocus.lib.uoc.gr/dlib/0/f/d/metadata-dlib-2005petraki_mer.tkl>.  
(pdf <https://publications.ics.forth.gr/_publications/Petraki.pdf>).


But true preservation needs continuous control if the words are still 
understood (as in oral tradition), .
This effort can be done only to a limited set of things, so we need a 
selection of what we want to remember. This requires an understanding of 
our cultures, do we have it?


Isn't it?

Best,

Martin

On 9/17/2023 9:42 AM, Гук Дарья Юрьевна wrote:

Dear all,
beeing out of discussion (too many reasons) I can add a metaphorical 
opinion.
Poem about Gilgamesh is known after clay peaces, broken, copied and 
fixed with adds, and are able to read it only with interpreter. The 
same with any file - machine readable data, wich are fixed phisically 
and accessed only by computer interpretator and electricity. Be sure, 
most part of files even printed has no sence for human. Are you 
interected, where are cleaning lady's rag? Never! Although it's 
ethnography. Conclusion: files exist only for robots.
Copies of video and sound as part of heritage are other thing 
presenting only specific part, but be sure, useless century years 
after creation. Maybe we need caracterize them by durance of use?


With kind regards,
Daria Hookk
----
*От:* Crm-sig  от имени Martin Doerr via 
Crm-sig 

*Отправлено:* 16 сентября 2023 г. 0:08:46
*Кому:* crm-sig
*Тема:* [Crm-sig] Issue 490: how to model a file [HW reminder]
Dear All,

Let me summarize the discussion about issue 490 between George, 
Christian-Emil and me, to be discussed in the next meeting:


"How to model a file" may be too vague.

There are three aspects:

A) What constructs are needed in the CRM ontologically to refer to the 
unique content of a file.


B) What constructs are needed to refer unambiguously to a resource 
that changes content. This is modeled in CRMpem as "Volatile Dataset", 
and will not be discussed in this issue.


C) How to connect in a knowledge base to a materialized content 
description.


About A):

We take a file (see also Persistent Dataset in CRMpem) in the sense of 
an immaterial E73 Information Object as a unique sequence of symbols 
that can be machine-encoded, regardless what groups of bits constitute 
one of the symbols of interest in this object.

   in the KB: The intended identity can be represented by a URI.

We take a file in the sense of a material copy on a digital medium as 
a kind of "E24 Human-Made Feature", regardless whether it is on a 
*local* installation, in a "*cloud*" cluster of machines, a *LOCKSS* 
federation of copies, or on a *removable* carrier.


    in the KB: We may refer to the material copy by an *external URL*, 
or create an *E52 String *in a KB or within an RDF file, or use a 
platform-internal  "*BLOB mechanism*" with whatever kind of identifier 
the platform refers to the local copy.


Ontologically, it is irrelevant for the intended immaterial content if 
the copy is printed or scribbled on a paper or on a digital medium (or 
even a Morse sound track), as long as the material form  is 
unambiguous wrt to the intended content. Both, paper and digital media 
can have errors. The CIDOC CRM v7.1 can be printed on paper and in 
principle be reentered manually into a file loss-free.


   in the KB: We may refer to a paper copy or a removable medium by an 
archival identifier.


About C)

Using an archival identifier for a paper copy, a removable digital 
medium or a URL for a file on a machine, in all cases the maintainers 
of the archive must guarantee that the identifier will be uniquely 
connected with the content. Otherwise, using a URL in a KB is simply 
inadequate.
The DOI organisation forsees penalties for users that change the 
content of a URL associated with a DOI. There is no other solution.


DOI *automatically redirects* from the DOI URI to the guaranteed URL.

The property P190 has symbolic is used to connect a machine-encodable 
information object to a KB inte

Re: [Crm-sig] Issue: Completing the list of shortcuts in CRMbase


Agreed with all!

Martin

On 10/4/2023 12:42 PM, Schmidle, Wolfgang via Crm-sig wrote:

Dear All,

P81 "ongoing throughout" and  P82 "at some time within" are strong shortcuts, 
but not yet marked as such:

E52 Time-Span P81 ongoing throughout E61 Time Primitive
E52 Time-Span P86i contains E52 (Declarative) Time-Span P170i time is defined 
by E61 Time Primitive
P81(x,y) ⇔ (∃z) [E52(z) ∧ P86i(x,z) ∧ P170i(z,y)]

E52 Time-Span P82 at some time within E61 Time Primitive
E52 Time-Span P86 falls within E52 (Declarative) Time-Span P170i time is 
defined by E61 Time Primitive
P82(x,y) ⇔ (∃z) [E52(z) ∧ P86(x,z) ∧ P170i(z,y)]

Christian-Emil suggested opening an issue for completing the list of shortcuts 
in CRMbase, and to create a separate issue for the extensions whenever 
necessary.

Best,
Wolfgang


___
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] Issue: P168i defines place shortcut

Dear Wolfgang,

We define shortcuts only for the very frequent cases. I proposed a
shortcut for approximating a place by a space primitive, because there
are millions of such data. We do not propose shortcuts when we regard
the documenation of the intermediate to be important for data
integration, such as birth events, in contrast to "birth date" etc.

The Space Primitive and all other primitives has an identity as a
limited set of internationally used symbols by electronic data devices.
The same geometric area can be described by many different space
primitives. Therefore, it is cannot be Isa place, isn't it? We need the
distinctions if notation and conversions become relevant. Different
electronic devices support different value ranges. At some place, we
need to be pragmatic. If we define an interface from an ontology of
being in the real world, obeying to FOL, to typical database constructs,
we necessarily encounter some special hybrids. For instance, 1/3 is a
number, but does not exits in any primitive value😁. "are not considered
elements of the universe of discourse the CIDOC CRM aims to define and
analyse" does not mean we do not use them. Making E94 being a subclass
of Appellation is a minimal statement about their role.

Best,

Martin

On 10/3/2023 9:41 AM, Schmidle, Wolfgang via Crm-sig wrote:

Okay, last one. I had overlooked P82 "at some time within", and of course there is also P172
"contains" and P81 "ongoing throughout". The questions about P171 also apply to P172 /
P81 / P82.

So many possible shortcuts. Was there a reason for not making E94 Space Primitive a subclass of E53 Place?
i.e. is it more on the side of "Period is a Spacetime Volume" or "Physical Thing defines but
is not a Spacetime Volume"? The E59 scope note says "The instances of E59 Primitive Value and its
subclasses are not considered elements of the universe of discourse the CIDOC CRM aims to define and
analyse", but with E94 being a subclass of Appellation this might no longer be entirely accurate anyway.

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] Issue: P168i defines place shortcut


Dear Wolfgang,

P189 is a superproperty of Q11, because it allows also phenomenal and 
mixed-type places to be used for approximation.


Indeed, if E53 Place P168 place is defined by : E94 Space Primitive, 
then it must be a Declarative Place. Hence, the shortcut


can be the same of "E53 Place Q11i is approximated by: SP6 Declarative 
Place Q10i is defined by : SP5 Geometric Place Expression (= E94 Space 
Primitive)"


I am not sure about the latest updated version of CRMgeo, because these 
are the constructs we harmonized later in CRMbase.


Best,

Martin

On 9/26/2023 11:25 AM, Schmidle, Wolfgang via Crm-sig wrote:

I assume that P189i is the same as Q11i in CRMgeo. Since the shortcut would be 
in CRMgeo anyway, would it make sense to define shortcuts for STVs and 
Time-Spans in CRMgeo as well? I.e. for

E93 Spacetime Volume Q12i is approximated by SP7 Declarative Spacetime Volume 
P169i spacetime volume is defined by E95 Spacetime Primitive

E52 Time-Span Q13i is approximated by SP10 Declarative Time-Span P170i time is 
defined by E61 Time Primitive

Best,
Wolfgang



Am 25.09.2023 um 11:20 schrieb Martin Doerr via Crm-sig :

Dear All,

I propose a shortcut in CRMgeo for E53 Place P189i is approximated by: E53 
Place P168 place is defined by : E94 Space Primitive,
for obvious practical reasons. It can have the same label.

Best,

Martin
--
----
Dr. Martin Doerr

Honorary Head of the
Center for Cultural Informatics

Information Systems Laboratory
Institute of Computer Science
Foundation for Research and Technology - Hellas (FORTH)

N.Plastira 100, Vassilika Vouton,
GR70013 Heraklion,Crete,Greece

Vox:+30(2810)391625
Email: 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


___
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] Issue: P168i defines place shortcut


Dear Wolfgang,

Good question! Actually I am confronted with applications with many many 
points approximating places. Normally, we would say, use P171, P172, but 
DO NOT define an approximation by a POINT nearby, if you can do better. 
For legacy data, this is hard to enforce. I regard P171,P172 a 
fundamental good practice for CRMbase. No reason to repeat in CRMgeo 
anything that is (now!) in CRMbase, isn't it?


Best,

Martin

On 10/1/2023 2:09 PM, Schmidle, Wolfgang via Crm-sig wrote:

Some additional questions:

P189 and P171:
E53 Place P171 at some place within E94 Space Primitive
is a strong shortcut of
E53 Place P89 falls within E53 Place P168 place is defined by E94 Space 
Primitive

Should P171 and the proposed "is approximated by" shortcut be either both in 
CRMbase or both in CRMgeo?

Would P171 be called "falls within" if it were introduced now?




--
--------
 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] Issue: P168i defines place shortcut