Re: [Crm-sig] Propose New Issue: Named Graph Usage Recommendations / Guideline Document

[George Bruseker]

Dear all,

I'm pleased to report that this issue has made the official SIG issue list:

http://www.cidoc-crm.org/Issue/ID-526-named-graph-usage-recommendations-guideline-document

For all interested parties to this issue with knowledge and experience, a
very warm welcome is extended to attend the session.

and is scheduled to be discussed in the second session of the first day of
the upcoming SIG, that is on Monday, March 8, 2021.

The official agenda due out soon.

Best,

George

On Thu, Feb 25, 2021 at 10:20 AM George Bruseker 
wrote:

> Dear all,
>
> Before the last SIG, together with CHIN, we proposed an issue on
> discussing best practice in the application of named graphs by the CIDOC
> CRM community. In order to empirically ground this conversation and build a
> background understanding of the present state of the art, CHIN and myself
> co-developed a survey which we shared to the list in order to get actual
> practitioner feedback on the use of named graphs. The results of that
> survey as well as preliminary conclusions regarding its content are listed
> in the attached report. In the report you will find a link to the original
> survey and the raw data resulting if of interest.
>
> So the groundwork and homework is done to have a fruitful conversation on
> this topic!We heartily look forward to discussing this issue at the
> upcoming SIG and will make sure to invite all respondents to the survey to
> attend the scheduled session. We look forward to the community based
> discussion on this question and building best practices together.
>
> Here is a link to the survey result report:
> https://drive.google.com/file/d/1vUBsp-AUrdE0_61CpsqBymQEzyzLvMzh/view?usp=sharing
>
> Sincerely,
>
> George
>
> P.S.: Sorry if this sends twice, the list bounced my email with a tiny
> attachment, so I had to find a workaround. Hope this does the trick!
>
>
>
> On Fri, Oct 30, 2020 at 2:07 PM George Bruseker 
> wrote:
>
>> Dear all,
>>
>> Given the packed agenda of the CRM SIG, we were not able to talk about
>> named graphs during the course of this SIG.
>>
>> I would hope to move the conversation forward significantly between now
>> and the next SIG in parallel with the work on issue 382
>> 
>>  on
>> provenance.
>>
>> To this end, together with CHIN, I have compiled a survey on named graph
>> use, that I would invite people/organizations in the community who are
>> interested in the question to answer. CHIN is actively researching this
>> issue and will compile the data and share it back to respondents and the
>> community in support of a general CIDOC CRM SIG recommendation on the use
>> of named graphs (similar to the RDF recommendation document work).
>>
>> The survey can be retrieved here:
>>
>>
>> https://docs.google.com/forms/d/e/1FAIpQLSeIPyE6uZ5r32G4Ejznk5E6X4rkj45fuEzj_Z9QzL2R_F07zA/viewform
>>
>> Sincerely,
>>
>> George Bruseker
>>
>> On Thu, Oct 22, 2020 at 4:21 PM George Bruseker <
>> george.bruse...@gmail.com> wrote:
>>
>>> Dear all,
>>>
>>> As a complement to the work going on in issue 382 on where to document
>>> and where not to document provenance, I suggest a parallel avenue of
>>> research/work related to the implementation of named graphs for data sets
>>> using CIDOC CRM. As named graphs are now commonly used in semantic data
>>> management, it seems apropos as a community to have a recommendation of
>>> good practice similar to what we have done with the RDF implementation
>>> document (outside of the spec, but related to real world use).
>>>
>>> This issue is something that is especially of interest to organizations
>>> involved in and intending to implement aggregations of CH datasets where
>>> the issue of named graphs have to do, inter alia, with both questions of
>>> provenance but also questions of maintenance and updating of the semantic
>>> data graph.
>>>
>>> To this end, together with Philippe Michon and the team at CHIN, we have
>>> been putting together a set of questions, to try to pick out the actual
>>> practice of named graph usage in the CIDOC CRM community as a basis from
>>> which to create a empirically grounded best practice
>>> recommendation/strategy.
>>>
>>> Time permitting, we would like to share our current ideas/questions
>>> during the SIG, and then share a survey with the community.
>>>
>>> Otherwise, we can continue this conversation virtually.
>>>
>>> Best,
>>>
>>> George
>>>
>>>
>>>
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Propose New Issue: Guidelines and Protocols for Translating CIDOC CRM

[George Bruseker]

Dear all,

Thanks already for your valuable feedback and uptake on this proposal. I am
pleased to say that this issue has been added to the official CRM SIG issue
list:

http://www.cidoc-crm.org/Issue/ID-528-guidelines-and-protocols-for-translating-cidoc-crm

It is also scheduled to be discussed in the afternoon session of the
upcoming SIG on Monday March 8th. I do hope everyone responding here and
all others interested in this topic will be available to share their
knowledge and help us move this subject forward.

Sincerely,

George

On Sat, Feb 27, 2021 at 8:50 AM Franco Niccolucci <
franco.niccolu...@gmail.com> wrote:

> Dear all,
>
> the appearance of this issue is the sign of the vitality, importance and
> diffusion of the CRM.
>
> Undertaking a transation poses a number of issues that need to be
> addressed before moving to practicalities.
>
> The “Canadian case” shows the need of complying with legal constraints.
> For example, if a country formally decides that the national standard for
> cultural heritage documentation is the CRM, the related decree will need to
> have an appendix with the CRM version approved, and I think that it would
> not be acceptable to include it in English, but it should be in that
> country’s national official language(s). Thus it is better to have an
> ‘approved' translation in advance, to guarantee that the ‘official’ text is
> a faithful one. This may also resolve contractual issues, for example with
> companies contracted to prepare heritage documentation compliant with CRM.
>
> On the other hand, using different translated versions of the CRM may - at
> least in principle - undermine its universality. Even if machine
> actionability would eventually be preserved, attention must be paid to the
> human side of the job, to guarantee that scope notes - for example - give
> the same meaning to labels acroos translations.
>
> What should be translated? Of course, the discursive part, as the
> introduction - the pages numbered with Roman numerals in the CRM
> description. But, they contain examples and references to Classes and
> Properties, for which the specific rules should apply. For example, the
> statement on page xi "In CIDOC CRM such statements of responsibility are
> expressed though knowledge creation events such as E13 Attribute
> Assignment and its relevant subclasses.” includes such a reference that
> must follow the translation rules for Class names.
> Another example is the “IsA” relationship. If translated, it contains the
> indeterminate article “A” which in some languages must follow the
> grammatical gender of the term it refers to, and thus gets two/three
> equivalents. So my choice would be to consider it as a symbol and keep it
> in English also in the translations. There may be other issues of this
> kind, so a general directive should be 1) established 2) accepted according
> to local constraints. I believe that the decision could be easy in this
> particular case; but it must be decided for all the similar occurrences.
>
> The above leads me to think that before undertaking any translation, the
> official English version should be examined to evaluate what is English -
> and may be translated - and what is symbolic and just seems English - not
> to be translated. IsA is an example, there may be others. The translation
> may be funny from a literary point of view (“Martin Doerr IsA un homme”),
> so an explanation could be given - maybe in a footnote - to help
> understandability.
>
> Naming conventions (pages xiv - xv) should of course be preserved. Here
> examples are given in Italic e.g. "*E53 Place. P122 borders with: E53
> Plac*e”. I am not completely clear with the need of a full stop after
> Place (could be a typo from copy-paste), but also the use of Italic is
> introduced surreptitiously. By the way, it is maybe high time to establish
> a recommendation to standardize how to quote class and property names e.g.
> in articles, in order to distinguish them from plain discourse also
> typographically.
>
> Coming to scope notes, I think that only the symbolic parts should remain
> in English, i.e. the alphanumeric label e.g. “E1”.
>
> The above are just examples of what a preventive survey of the official
> English text will define as “not translatable”. In my opinion it wouldn’t
> take much time to fo it.
>
> The next step is what George calls “translation rules”. I am looking
> forward to fierce debates about the translation of “Human-made”, if it
> should follow the style of the Nusée de l’Homme (“fait par l’homme”) or
> choose a gender-neutral “anthropogenic” or whatever else.
>
> I agree with George on the necessity of general guidelines and protocols
> to translation. But since these depend on the culture behind the language
> into which the CRM is going to be translated, accepting them is not
> automatic: how can a native English (or Greek, or German) speaker decide
> what is better for Italian or French? So such protocols should be stated 

Re: [Crm-sig] Issue 511

[Robert Sanderson]

Martin wrote in particular:
  Reduce in CRMbase Mesaurement , P40 observed dimension, to E18 Physical
Thing. Add 3 different properties “has dimension” in CRMBase to E70 Thing,
E53 Place, E4 Period (or E2 Temp Entity).

I agree with your argumentation, and believe that the changes in CRM Base
would be:

P39 measured:
  Range changes from E1 CRM Entity to E18 Physical Thing

PXX1_has_dimension
  Domain: E53 Place
  Range: E54 Dimension

PXX2_has_dimension
  Domain: E4 Period
  Range: E54 Dimension

to be cognate with P43 has dimension for E70s.

The question would remain about the measuring of Non-physical Things, such
as the number of symbols in a E90 symbolic object... but I don't have that
use case, so am happy to leave the discussion to someone that does :)

Rob

On Tue, Mar 2, 2021 at 4:31 PM Martin Doerr  wrote:

>
>
> *Posted by Robert Sanderson on 9/9/2020*
>
> I believe that there is an inconsistency in the model for measurements and
> dimensions.
>
> E54 Dimensions are associated directly with E70 Things using P43 has
> dimension.  So not every class can have dimensions, only those that are
> descendents of E70.
>
> However E16 Measurement's property P39 measured has a range of E1 CRM
> Entity, meaning that while (for example) an E53 Place cannot have a
> dimension, it can be measured to have a dimension. This seems inconsistent
> that an entity that cannot have dimensions can still be measured.
>
> I propose that the range of P39 measured be changed to E70 Thing to
> resolve this inconsistency.
>
>
>
> We have to distinguish measurement from dimension. In order to measure
> something in a narrower sense, I need an observation of something material.
> Dimensions can also be result of computation, evaluation and estimation
> (forms of Attribute Assignment).
>
> If we look at measuring in the narrower sense, we can count the characters
> of a text on paper, but not the abstract text. The logical representation
> of a text can be evaluated for its dimensions.
>
> We cannot measure a place, but features at a place. See also Issue 388.
> But clearly, we can measure duration and extent of processes, and comparing
> a clock, which provides a duration from the last sync event, with some
> other transient situation or microevent, in order to calculate absolute
> time.
>
> So, we may assign the ability to be observed to E18 physical things and E4
> Period, or more narrowly to E5 Event.  The ability to be observed appears
> to need some common ontological nature, a certain materiality interacting
> with measurable signals. Even the lightning creates a plasma hose lasting
> some milliseconds. That would need a new class “Observable Entity” as range.
>
> Otherwise, we may regard measuring physical things and measuring processes *as
> independent*. Then, we would need *another measurement class*, such as
> “static measurement” versus “dynamic measurement”.
>
> Dimensions of other things, such as places in the abstract geometric sense
> of the CRM, need not be based on a common property. The place can only have
> diameters and areas as dimentions, and may be some more exotic ones. The
> dimension in the phenomenal timespan is of course that of the respective
> period etc. So, my argument being that E53 Place, E52 Time-Span have their
> own properties with range Dimension, without being regarded as observable
> (rather results of observation).
>
> I’d propose the following:
>
> Reduce in CRMbase Mesaurement , P40 observed dimension, to E18 Physical
> Thing. Add 3 different properties “has dimension” in CRMBase to E70 Thing,
> E53 Place, E4 Period (or E2 Temp Entity).
>
> Extent CRMSci by E18, E4 IsA Observable Entity, and extend Mesaurement P40
> observed dimension,  from E18 to Observable Entity.
>
> Alternatively, introduce “Dynamic Measurement”  in CRMSci.
> Best,
>
> Martin
>


-- 
Rob Sanderson
Director for Cultural Heritage Metadata
Yale University
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Question: How to model a 'file'

[Martin Doerr]

Dear Daria,

I have the impression you never got an answer to this question, because 
it was filed by mistake under ISSUE 490, "How to model a file"!


The answer to your question is:

step 1 - modeling
step 2 - decision

Are Activity Types (E55 Type). Step 1, step 2 give positions in a 
framework schema, another E55, "Daria's Modeling Workflow".


If you instantiate step 1 - modelling, you create a particular instance 
of E7 Activity, has type :"Modelling (Step1)", with label "my first 
attempt" or so.

Same for step2.

Then you have the generic instruction, "return to step 1", which means, 
you create a new instance of E7 Activity, has type :"Modelling(Step1)". 
with label "my second  attempt" or so.


All the framework schema tells you, which inputs of the first attempt to 
reuse in the second, and what to change.


Please let me know if this answer is adequate!

Best wishes,

Martin

On 4/16/2020 11:30 AM, Дарья Юрьевна Гук wrote:

Dear friends,

I am not sure for clear understanding the model of "Activity", please 
check it if the situation is repeatble (reality):

step 1 - modeling
step 2 - decision
step 3 - return to the step 1 (re-modeling, improvements or renovation)
The same thing exiats in digital world as in reality and even fixed in 
State standrds (in Russia).


With kind regards,
Daria Hookk

Senior Researcher of
the dept. of archaeology of
Eastern Europe and Siberia of
the State Hermitage Museum,
PhD, ICOMOS member

E-mail: ho...@hermitage.ru 
Skype: daria.hookk
https://hermitage.academia.edu/HookkDaria 



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

[Martin Doerr]

Dear All,

Let me take up this issue, after new considerations:

Background:

**

*Posted by Robert Sanderson on 9/9/2020*

Dear all,

I believe that there is an inconsistency in the model for measurements 
and dimensions.


E54 Dimensions are associated directly with E70 Things using P43 has 
dimension.  So not every class can have dimensions, only those that are 
descendents of E70.


However E16 Measurement's property P39 measured has a range of E1 CRM 
Entity, meaning that while (for example) an E53 Place cannot have a 
dimension, it can be measured to have a dimension. This seems 
inconsistent that an entity that cannot have dimensions can still be 
measured.


I propose that the range of P39 measured be changed to E70 Thing to 
resolve this inconsistency.


I would also be okay with the other direction by changing the domain of 
P43 has dimension to be E1 CRM Entity, however that seems like a much 
more significant change, and would result in quite strange side effects 
such as Dimensions having Dimensions.


……

*Posted by Robert on 9/9/2020*

Thanks Thanasis.  Yes, there's various dimensions that are associated 
with non-Things, and I agree that Place is particularly easy to justify.


Place:  Area. The county of Los Angeles has a dimension of 4751 square 
miles. If the place is approximate, then the radius of a centroid would 
be an obvious dimension to record, or height/width for bounding box 
defined Places.


Time-Span:  Duration is already a property of a Time-Span that refers to 
a dimension (P191). This could then be a subproperty of P43, or 
deprecated in favor of a classification on the Dimension.


Temporal Entity and Spacetime Volume are a bit strange in relation to 
Time-Span. Does the Period have the duration or the Time-Span, or both? 
What if they're different


Conversely Dimensions seem like they should not have Dimensions.

We have to distinguish measurement from dimension. In order to measure 
something in a narrower sense, I need an observation of something 
material. Dimensions can also be result of computation, evaluation and 
estimation (forms of Attribute Assignment).


If we look at measuring in the narrower sense, we can count the 
characters of a text on paper, but not the abstract text. The logical 
representation of a text can be evaluated for its dimensions.


We cannot measure a place, but features at a place. See also Issue 388. 
But clearly, we can measure duration and extent of processes, and 
comparing a clock, which provides a duration from the last sync event, 
with some other transient situation or microevent, in order to calculate 
absolute time.


So, we may assign the ability to be observed to E18 physical things and 
E4 Period, or more narrowly to E5 Event.The ability to be observed 
appears to need some common ontological nature, a certain materiality 
interacting with measurable signals. Even the lightning creates a plasma 
hose lasting some milliseconds. That would need a new class “Observable 
Entity” as range.


Otherwise, we may regard measuring physical things and measuring 
processes *as independent*. Then, we would need *another measurement 
class*, such as “static measurement” versus “dynamic measurement”.


Dimensions of other things, such as places in the abstract geometric 
sense of the CRM, need not be based on a common property. The place can 
only have diameters and areas as dimentions, and may be some more exotic 
ones. The dimension in the phenomenal timespan is of course that of the 
respective period etc. So, my argument being that E53 Place, E52 
Time-Span have their own properties with range Dimension, without being 
regarded as observable (rather results of observation).


I’d propose the following:

Reduce in CRMbase Mesaurement , P40 observed dimension, to E18 Physical 
Thing. Add 3 different properties “has dimension” in CRMBase to E70 
Thing, E53 Place, E4 Period (or E2 Temp Entity).


Extent CRMSci by E18, E4 IsA Observable Entity, and extend Mesaurement 
P40 observed dimension,from E18 to Observable Entity.


Alternatively, introduce “Dynamic Measurement”in CRMSci.

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