Re: [Crm-sig] HW issue 556

[Dominic Oldman via Crm-sig]

Hi Martin,

Thanks for this.

When looking at this I started thinking about some projects I have been
working on where, in one case, researchers are interested in the evolving
landscape as markers for changes in the way people lived (and their
conditions) and in another where administrative decisions (colonial) are
based on hydrology surveys.

I think this is a useful practical abstraction.

Cheers,

Dominic




On Tue, 5 Sept 2023 at 09:04, Martin Doerr via Crm-sig 
wrote:

> Dear All,
>
> Some years ago we analyzed place types from different gazetteers, with the
> focus on  such phenomena with a relevant spatiotemporal 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
>
> ___
> 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

[Crm-sig] Ontology Extension - CRMInfluence

[Dominic Oldman via Crm-sig]

Please find a link to the draft of a new CIDOC CRM ontology extension by
Martin Doerr and myself.

https://www.dropbox.com/s/yvezaqkdq9lbh0f/About_Influence_For%20Distribution.pdf?dl=0

Martin and I look forward to a discussion of this paper.

Thanks,

Dominic
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

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

[Dominic Oldman via Crm-sig]

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 <
> crm-sig@ics.forth.gr> 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 

Re: [Crm-sig] PC0_Typed_CRM_Property in CRMpc

[Dominic Oldman via Crm-sig]

Hi

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

D

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

> Dear Robert,
>
> We have just created the new issue to discuss this in detail. We should
> prepare a detailed analysis, citing all pros and cons. May be we continue
> this discussion better in a subgroup?
>
> Named Graphs are not a very specific technology, if we take the fact that
> all current triple stores are actually implemented as quad stores,
> regardless whether they call the construct "Named Graph" or "context". We
> have used and implemented this feature, and it is very performant. It runs
> on BlazeGraph as well. I think their is not a simple answer to that.
> Performance can become a major issue, when you have really a lot of data.
>
> For the attribution of artists and "style of" vs "school of" etc. of the
> collection management system of the British Museum, the ResearchSpace
> Project had created a set of subproperties of P14 carried out by, which
> could be used as input for a roles vocabulary.
>
> I did not propose to use Dig as is, but to consider the construct. The W3C
> annotation model is very interesting. We would need a connection to the
> Creation Event of making an annotation, and whose opinion it is, in order
> to make it CRM compatible. Why not allowing a Named Graph as target?  We
> should compare the segment construct of the W3C annotation model with the
> METS  types and extensions we used. The Dig model was used to trace
> provenance of annotated area through transformations of digital objects.
> That was very important for exchanging research insights on 3D models. To
> be discussed!
>
>  We can extend E13 to Proposition Sets, which would be very important to
> describe consistently CRMinf and generalized observations. That would then
> be most effectively implementd via Named Graphs.
>
> Opinions?
>
> Best,
>
> Martin
>
> On 5/11/2023 3:41 PM, Robert Sanderson wrote:
>
>
> If the intent is that the assertion is in the discourse, and not a
> syntactic workaround for .1 properties that would be unnecessary if we had
> RDF* or property graphs, then I would say E13 is exactly the right approach
> to use. In comparison, I consider the PC classes to be just that - a
> syntactic work around needed in RDF and not part of the discourse. In
> LInked Art, in a discussion around uncertain attribution of artists and
> "style of" vs "school of", we posited the need for a property on E13 for
> this scenario. (Also the need for .1 on P11 for the same reason as we have
> it on P14)
>
> I would say that Dig's annotation is *not* the correct approach for
> several reasons:
> * Named Graphs are a very specific technology that have never seen
> significant uptake and are likely (IMO) to decrease in usage once RDF* is
> formalized.
> * Dig needs to be updated, and Annotation is (I would hope) likely to go
> away ... because ...
> * ... it could just use the Web Annotation Data Model:
> https://www.w3.org/TR/annotation-model/
>
> (And reification has all the problems discussed in this thread already)
>
> Rob
>
>
> On Thu, May 11, 2023 at 7:17 AM George Bruseker via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> Dear Martin,
>>
>> I agree that E13 is a poor man's solution to a complicated problem. But
>> it is for some, the solution available. Other solutions like Inf for
>> documenting historical argumentation and using named graphs is great as a
>> possibility. Using prov o to represent the meta discursive level of the
>> provenance of the dataset as such great. But my immediate interest was
>> simple the humble ability of E13 to be able to point to all statements that
>> can be made with precisely one link in CRM.  I'll keep watching the space!
>>
>> Cheers,
>>
>> G
>>
>> On Thu, May 11, 2023 at 1:25 PM Martin Doerr  wrote:
>>
>>> Dear George,
>>>
>>> I agree with you below about the historical aspects. The annotation
>>> model has the same historical aspect, but is not limited to a single link.
>>>
>>> Let us discuss!😁
>>>
>>> Best,
>>>
>>> Martin
>>>
>>> On 

[Crm-sig] What CIDOC-CRM can do, and what it can not

[Dominic Oldman via Crm-sig]

I wanted to comment on email exchanges that have taken place over recent
times. CIDOC CRM is a major achievement, not just in cultural heritage, but
in the humanities generally. The founding members of the CRM and others
that joined them in the CRM SIG achieved what Knowledge Representation (KR)
computer scientists were unable to achieve when they first described KR.
Their concept of KR was clear - it relies on making a connection between
“problem solving expertise” and “the domain” in which this problem solving
takes place. The key element was the latter, which needed to provide a
solid framework of representing reality.

Without a reality based domain framework they knew that integration of
information could not be achieved - they understood that it was impossible
to effectively integrate on an epistemological basis (see Davis, Shrobe,
Szolovits (1993), What Is a Knowledge Representation).  However many
computer scientists were unable to undertake this arduous task of
describing the reality of a domain (and they explicitly replaced ‘ontology’
with ‘schema’ to clarify that they had removed this burden - although this
naming practice has not been continued) and focused on reasoning
experiments with epistemological information.

The CRM SIG achieved what computer scientists couldn’t themselves, and
didn’t, because it required a significant empirical investigation demanding
many years of work in another domain. The CIDOC CRM attempts to find points
of integration across and within different disciplines. These points of
integration are the connection between reality and practice. CIDOC CRM
concepts need to be both universally accepted and be capable of being
universally applied. This is what provides a robust semantic framework for
integrating information. In the highly fragmented, disjointed and
unreliable world of the digital and the Web, the CRM stands out as a robust
framework for interdisciplinary work and engagement. We know only too well
in cultural heritage that the efforts to aggregate the different structures
and languages with different epistemological traditions without an
ontological framework has only led to reductive implementations that are of
limited value long term.

The construction of our integrating ontology, which is one of relatively
few that complies with the original KR blueprint, could only have been
achieved with the huge effort of CRM SIG members and in particular those
founding members who established the fundamental key principles. We should
consider the increased activity in developing more specialisations as an
indication of the success of the CIDOC CRM - but these specialisations
cannot be epistemological constructions regardless of how probable or
possible they are. They must be compatible with the principle of domain
reality through robust empirical examples and practice. Without it, the
ontology just becomes yet another schema, and will become fragmented like
the academy. The CRM SIG works on clear principles and not on the invention
of schemas to satisfy pragmatic individual needs, meet artificial project
deadlines, support pragmatic epistemology bubbles, or satisfy commercial
contracts. The CRM is based on transparency and understanding, not closed
shops.

In the midst of this a worrying trend has appeared in that the CRM SIG has
become, in some instances, an environment which prevents open discussion
and which lacks the appropriate professional standards and courtesy needed
in communication, and this is not appropriate. The principles and
methodology of the CIDOC CRM are clear and have been described in much
detail over many years. The founding designers of the CIDOC CRM are people
who have wide interests, discuss many different subjects and are very open
and accessible. For a recent example, I discussed with a CRM colleague the
subject of social class, which is of great importance to me and historians
tracking social change and transition. I have very clear thinking about,
and use the concept of, social class, and other aspects of society which
are an important part of my work, but I doubt that everyone would agree
with my conceptions.  We can talk and agree about their importance, and
existence, but they are not concepts that can be defined under the CIDOC
CRM methodology and framework which require clear boundaries.  For example,
from Bourdieu’s essay “What Makes a Social Class? On The Theoretical and
Practical Existence Of Groups”,

“In the reality of the social world, there are no more clear boundaries, no
more absolute breaks, than there are in the physical world. The boundaries
between theoretical classes which scientific investigation allows us to
construct on the basis of a plurality of criteria are similar, to use a
metaphor of Rapoport's, to the boundaries of a cloud or a forest. These
boundaries can thus be conceived of as lines or as imaginary planes, such
that the density (of the trees or of the water vapour) is higher on the one
side and lower on the other

[Crm-sig] FYI - CIDOC CRM and ResearchSpace at the The National Archives (UK)

[Dominic Oldman via Crm-sig]

[https://lh3.googleusercontent.com/itpehTpPJgjUsWPk1h-WkLxFFcfJph2adZGbcgrirYudbYAgZ-r9IMQI6sJi7bV5FZXa2y5aL1TYDon6D58kFSLf_R9xykq2E7c8Nh8D3Qacq1-NQ9XEMkEJPKZmyP2zFzDHfuMm]

The National Archives implement the ResearchSpace Knowledge Graph Platform to 
provide a dynamic and contextualising system

The National Archives (TNA) has implemented a new institutional digital system 
in its Collection Care department using ResearchSpace, a system that captures 
the knowledge and processes of cultural heritage and humanities professionals 
and using the CIDOC CRM (Conceptual Reference Model). This new system records 
both conservation practice and research with provenance and historical context. 
It provides experts with a flexible and expandable information system that 
dynamically grows as processes change.
The  National Archives’ Collection Care Department, a centre of excellence in 
the field of archive conservation, guards and ensures access to the UK national 
archives through preservation and display, innovative sector-leading treatment 
and research, environmental management, and increasingly through collaboration 
and the exchange of information and context.

ResearchSpace, a semantic and contextually driven system, developed at the 
British Museum with support from the Andrew W. Mellon Foundation, will help the 
Collection Care Department support these activities and develop internal 
skills. It creates the means to answer questions about conservation practice, 
research and priorities and link conservation to wider issues of social and 
historical significance and inclusiveness. (http://researchspace.org)

This implementation reflects the TNA’s progressive approach to conservation 
practice and research and represents a step change in the way that computer 
systems are used as more than essential finding aids and reference systems. 
ResearchSpace is an open source knowledge system that can help represent and 
integrate knowledge from different disciplines, communities and perspectives, 
and remove fragmentation from information and knowledge processes. As such it 
will support TNA Collection Care in addressing new challenges and information 
needs, and represent innovative and socially aware thinking.

The system is supported by Kartography (http://kartography.org), a Community 
Interest Company that specialises in data contextualisation (historical and 
social significance and relevance), the equality of representation in data, and 
the development of the ResearchSpace system. It develops collaborative systems 
drawing from wider and diverse sources of knowledge.

Juergen Vervoorst, Head of Collection Care at the TNA said: “The National 
Archives has documented the conservation treatment of its collection for over 
170 years, but traditionally that data has been difficult to access and to 
share. ResearchSpace offers unique ways to change that: it allows us to share 
our thinking and decision making and will provide a deeper understanding of our 
collection and in particular its materiality. It will enable us to make links, 
where we didn’t see any, and to inform our thinking to the benefit of our 
collection.”

Sonja Schwoll, Head of Conservation and Treatment Development at the TNA said: 
“In the last 20 years, the Collection Care Department has redefined the role 
and competencies of today’s practicing conservator from a bench based treatment 
focused work focus to a framework around the practitioner researcher. With this 
new understanding our teams in Collection Care undertake research lead practice 
next to traditional aims of providing care and access to our collection items. 
The implementation of the ResearchSpace knowledge system is a representation 
and manifestation of our work as practitioner researchers: it allows for the 
first time in our history the documentation, development and dissemination of 
the full extent of our work in the Collection Care Department. As the Centre of 
Excellence and leader in archive conservation, we are supporting the further 
development of this open source system and its tools for wider use and 
application in the Heritage Sector.”

Athanasios Velios, Reader in Documentation, Ligatus, University of the Arts 
London said: “The implementation of the knowledge system in TNA is setting the 
standard in conservation documentation at a national and global level for two 
reasons: a) TNA, through the adoption of Linked Data, is willing to commit to 
sharing documentation records for the benefit of the conservation profession 
and the broader research and b) the technical implementation of the system 
through ResearchSpace is proof that flexible conservation documentation systems 
are practical and deployable. Alongside survey forms with fixed structures, it 
is now possible to customise documentation for specific objects using 
structured data without compromising uniformity of search. This implementation 
follows on from the Linked Conservation Data project, a key 

[Crm-sig] Equality and Respect Statement

[Dominic Oldman via Crm-sig]

Dear SIG members,

I respectfully submit a draft for comment towards a CIDOC CRM Equality and 
Respect Statement for the reference.

Thanks,

Dominic


CRM SIG - Equality & Respect Statement

Version: First Draft

Date: 12 October 2021



---

The current CIDOC CRM reference says this:

“The CIDOC CRM is specifically intended to cover contextual information: the 
historical, geographical and theoretical background that gives museum 
collections much of their cultural significance and value”.

New wording:

The CIDOC CRM Special Interest Group (SIG) is a collaboration of people 
developing the CIDOC CRM (Conceptual Reference Model) standard. The CIDOC CRM 
standard is used by many Cultural Heritage and Humanities professionals and 
institutions across the world. It is committed to promoting equality of 
representation and participation in its activities, whether in relation to the 
standard itself, or supporting wider processes. As a standards committee, we 
will treat all people with dignity and respect in an environment free of 
discrimination. Our aim is to encourage open and constructive dialogues and 
provide an environment in which all participants feel comfortable to take part 
and contribute.

The CIDOC CRM itself is intended to support the development of contextual 
information in data: the social, historical, geographical, and theoretical 
background that gives historical collections, archives, and facts much of their 
significance and relevance. It also provides the means to include 
epistemological information through an argumentation extension. It allows and 
encourages data owners and users to widen the scope and sources of information 
that are used in datasets, which can be limited by some traditional practices 
that focus on intrinsic material and identity properties. This means that 
datasets can often omit relevant socio-historical and epistemological 
information from the data history record.

CIDOC CRM is not prescriptive in terms of the types of information that can be 
modelled and documented, and its design intention is to include a wider range 
of knowledge. It provides a scientific framework pegged to universally 
understood reality and therefore provides the opportunity - which corresponds 
to a responsibility - to record contextual information including the social 
relations which are part of history and heritage. In practice it provides the 
means to consider a wider and inclusive picture of historical information. The 
general trend of institutions publishing their data online, and allowing its 
reuse across other information structures, only increases the urgency of this 
issue.

The legacy of structured data in institutional databases based on intrinsic 
data schemas is historically ingrained not just in technology but also in 
practices. It is important to note that it is not simply the use of CIDOC CRM 
or other contextualising models that is important. Contextual and inclusive 
enrichment of data to provide equality of representation is part of a reform of 
institutional processes generally and is an ongoing responsibility. 
Institutions should be constantly aware of the wider significance and relevance 
of their data (and missing data) in terms of their internal processes and the 
tools they adopt to support them. The CIDOC CRM SIG is committed to providing 
examples and guidance that demonstrate how currently underrepresented or 
missing history can be addressed in structured data systems and is open to 
anyone requiring more information and advice.


Dominic Oldman
Head of ResearchSpace, Senior Curator
Dept. Egypt and Sudan
British Museum
www.britishmuseum.org<http://www.britishmuseum.org/>
www.researchspace.org<http://www.researchspace.org/>

___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] New Issue: Non-human Actors

[Dominic Oldman via Crm-sig]

Hi

Just for clarity (I'm not sure whether George's reference was to me), my 
argument was that there are many practical things we can do to encourage 
historical contextualisation with the CIDOC CRM without any model changes, 
which we should be paying more attention to, and this is related to the scope 
of traditional documentation practices and museum documentation worldviews. I 
think this is a significant and large issue. I will release a sub-committee 
statement addressing this during the week to the CRM SIG which covers wider 
contextualisation and issues like mutual respect.

I think I understand at a high level the broad issues on both sides of this 
argument, and I can see from the tone of the discussion that the disagreement 
requires further investigation, and I would certainly like the opportunity and 
time to talk to people and read about these issues myself.

It is key to me, and the reason I, and others, became involved in the ontology, 
that it adheres to certain scientific principles.

I think it would be helpful to restate these principles clearly so that at the 
very least we have a proper starting point for these discussions, which would 
also be helpful to anyone reading these discussions and wanting to contribute. 
I will initiate something along these lines.

Cheers,

Dominic


From: Crm-sig  on behalf of George Bruseker via 
Crm-sig 
Sent: 12 October 2021 08:18
To: Martin Doerr 
Cc: crm-sig@ics.forth.gr 
Subject: Re: [Crm-sig] New Issue: Non-human Actors

Hi Martin,

I'm also pressed for time but above wrote out an argument.

Best,
George

On Tue, Oct 12, 2021 at 10:17 AM Martin Doerr 
mailto:mar...@ics.forth.gr>> wrote:
Hi George,

I'd prefer to let the biologists talk about that. To my best knowledge
of real cases, this is a much debated question. For the time being, I am
sorry I have no time to provide details.

All the best,

Martin


On 10/12/2021 10:02 AM, George Bruseker wrote:
> On the expertise question, I am not sure if we required a biologist to
> be able to model the notion of Birth or Death.


--

  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] New Issue

[Dominic Oldman via Crm-sig]

Dear All,

Just adding to Martin's note.

The current CIDOC CRM says

“The CIDOC CRM is specifically intended to cover contextual information: the 
historical, geographical and theoretical background that gives museum 
collections much of their cultural significance and value”.

The practice in which organisations simply transfer their existing data to a 
new technology/standard without reviewing its contextual content creates 
several issues in terms of the contextual integration of data, communicating 
significance and relevance to wider audiences through data, and connected to 
this, and as we have discussed at the first meeting of the CRM Equality and 
Respect meeting, perpetuating inequality of representation in data. This is 
particularly important because many CH organisations directly publish their 
documentation records to the public as part of audience communication.

We propose a specific and regular CRM SIG discussion about how to promote the 
contextualising principles of the CRM - since this is a core aspect of the 
CIDOC CRM - and address these issues by improving and disseminating information 
about the relevance of the CIDOC-CRM for organisations beyond existing 
documentation scopes.

Thanks,

Dominic


From: Martin Doerr 
Sent: 21 September 2021 20:11
To: crm-sig 
Cc: Dominic Oldman 
Subject: New Issue

Dear All,

Dominic Oldman and I would like to raise a new issue:

Whereas large efforts concentrate on migrating legacy data into CRM format, and 
the CRM is not meant to prescribe what to document, guide-lines and incentives 
for an optimal use of the ability of the CRM to create and cross-correlate 
contextual data might have a positive impact on the practice CH documentation, 
including mehods such as knowledge extraction from texts etc.

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<mailto: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 519: Homework to propose deprecation of P48, P54

[Dominic Oldman]

Hi All, (Sorry send key accidently)

This may well be the right approach, but I had a general point about these 
areas.

It would be useful to know the rationale behind them in the first instance. It 
occurred to me that perhaps the CIDOC-CRM needs to have some kind of associated 
knowledge base around it that points to the empirical work or evidence that led 
to the property in the first place so that we understand the origins of 
something. This is particular important as time goes by and different people 
join. So, it could be that items were, in hindsight, a mistake - that they are 
just vocabulary not ontology and not justified by practice, that they are 
borderline and there is a case for rationalisation, or that there has been a 
change of approach to these items.

It may be that we have some provenance here and I just need to look through the 
SIG forum etc. But I wonder whether this should be more formalised. This would 
strengthen the CIDOC CRM and provide more trust - but in any event the CIDOC 
CRM is not a top down ontology - it is a researched ontology and as an object 
of research it should be able to point to its underlying research, which is how 
the CRM should then be subsequently used - ontological commitments based on 
evidence.

Cheers,

Dominic


From:
Dominic Oldman 
Sent: 08 March 2021 08:25
To: Robert Sanderson ; crm-sig 
Subject: Re: [Crm-sig] Issue 519: Homework to propose deprecation of P48, P54

Hi All,

This may well be the right approach, but I had a general point about these 
areas.

But it would be useful to know the rationale behind them in the first instance. 
It occurred to me that perhaps the CIDOC-CRM needs to have some kind of 
knowledge base around it that points to the empirical work that led to the 
property in the first place so that we understand the origins of something. So, 
it could be that items were, in hindsight a mistake - that they are just 
vocabulary not ontology and not justified by practice, that they are borderline 
and there is a case for rationalisation, or that there is a change of approach 
to these items.

From: Crm-sig  on behalf of Robert Sanderson 

Sent: 03 March 2021 20:49
To: crm-sig 
Subject: [Crm-sig] Issue 519: Homework to propose deprecation of P48, P54

Dear all,

Thanks to Eleni for sending out the agenda and thereby reminding of our 
homework!

The proposal is to deprecate two properties, P48 has preferred identifier and 
P54 has current permanent location, following on from the conclusion of the 
discussion around the proposed property of 'has current permanent custodian' in 
issue 473.

As I recall it, the rationale for not adding 'has current permanent custodian' 
was not that the property did not make sense (it did) and not that it was not 
useful (it is), but that it was not necessary to add, as it is possible to add 
a classification to the activity that has the result of the transfer of 
custody, as to whether it is temporary or permanent.

The consequence of this was a (brief) examination of the specification for 
other properties where this pattern would be applicable, with the obvious 
deprecation candidates of P48 and P54.
The remediation pattern for P48 would be to add P2_has_type to the E41 
Identifier to indicate preferred-ness, or the E13 attribute assignment / E15 
Identifier Assignment of the identfier to the identified entity.
The remediation pattern for P54 would be to add a P2_has_type to the E9 Move to 
the location, in the same way that the resolution for 473 was to add 
P2_has_type to the Transfer of Custody.

The proposal should be considered separable -- not accepting the deprecation of 
P48 is not grounds for not accepting the deprecation of P54.

Rob

--
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] Issue 519: Homework to propose deprecation of P48, P54

[Dominic Oldman]

Hi All,

This may well be the right approach, but I had a general point about these 
areas.

But it would be useful to know the rationale behind them in the first instance. 
It occurred to me that perhaps the CIDOC-CRM needs to have some kind of 
knowledge base around it that points to the empirical work that led to the 
property in the first place so that we understand the origins of something. So, 
it could be that items were, in hindsight a mistake - that they are just 
vocabulary not ontology and not justified by practice, that they are borderline 
and there is a case for rationalisation, or that there is a change of approach 
to these items.

From: Crm-sig  on behalf of Robert Sanderson 

Sent: 03 March 2021 20:49
To: crm-sig 
Subject: [Crm-sig] Issue 519: Homework to propose deprecation of P48, P54

Dear all,

Thanks to Eleni for sending out the agenda and thereby reminding of our 
homework!

The proposal is to deprecate two properties, P48 has preferred identifier and 
P54 has current permanent location, following on from the conclusion of the 
discussion around the proposed property of 'has current permanent custodian' in 
issue 473.

As I recall it, the rationale for not adding 'has current permanent custodian' 
was not that the property did not make sense (it did) and not that it was not 
useful (it is), but that it was not necessary to add, as it is possible to add 
a classification to the activity that has the result of the transfer of 
custody, as to whether it is temporary or permanent.

The consequence of this was a (brief) examination of the specification for 
other properties where this pattern would be applicable, with the obvious 
deprecation candidates of P48 and P54.
The remediation pattern for P48 would be to add P2_has_type to the E41 
Identifier to indicate preferred-ness, or the E13 attribute assignment / E15 
Identifier Assignment of the identfier to the identified entity.
The remediation pattern for P54 would be to add a P2_has_type to the E9 Move to 
the location, in the same way that the resolution for 473 was to add 
P2_has_type to the Transfer of Custody.

The proposal should be considered separable -- not accepting the deprecation of 
P48 is not grounds for not accepting the deprecation of P54.

Rob

--
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] New Issue: Re-label E22, E25, E71 to remove "Man-"

[Dominic Oldman]

I strongly agree with Florian.

It is simply right to make these changes.

D



From: Crm-sig  on behalf of Florian Kräutli 

Sent: 12 April 2019 11:35
To: Pierre Choffé; Athanasios Velios; crm-sig@ics.forth.gr
Subject: Re: [Crm-sig] New Issue: Re-label E22, E25, E71 to remove "Man-"

Dear Pierre and all,

I strongly disagree. This is not about the origins of the word but of its usage 
and meaning in present day. The CRM should reflect (changing) knowledge 
contexts and we as a community should react to and respect developments in the 
world, and not decide based on our personal opinions about them.

I think this should be put up as an issue and I would vote in favour of either 
suggestion: dropping ‘man’ or replacing it with ‘human’.

Best,

Florian




On Fri, Apr 12, 2019 at 12:13 PM +0200, "Pierre Choffé" 
mailto:choffepie...@gmail.com>> wrote:


Dear all,

This subject is typical of the politically correct attitude of our times and 
most people (including me) generally avoid getting involved in such discussions 
- especially on social media where you would immediately get drowned in a flood 
of insults - and the result is that we have a feeling of consensus on the 
matter.

Now, we as a community might have a different point of view, starting with the 
knowledge we have of the origin of the word "man" (please consult the wikipedia 
page for a brief introduction). Can 
we please avoid this kind of discussions and leave it to Twitter and Facebook ?

Et pax in Terra hominibus bonae volontatis... (any woman feeling excluded here 
?)

Have a nice day,
Pierre



On Fri, Apr 12th, 2019 at 11:2 AM, Athanasios Velios  
wrote:

I support the change of the English labels to:

E22 Made Object
E25 Made Feature
E71 Made Thing

And I think this can be proposed as an issue to be voted through the SIG
list.

All the best,

Thanasis


On 12/04/2019 05:38, Robert Sanderson wrote:
> Dear all,
>
> On behalf of the Linked Art consortium, I would like to propose that the
> labels for E22 Man-Made Object, E25 Man-Made Feature and E71 Man-Made
> Thing be changed to drop the unnecessarily gendered “Man-“. In this day
> and age, I think we should recognize that inclusion and diversity are
> core features of community acceptance, and that including gender-biased
> language is alienating.
>
> Thus the proposal is: E22’s label should be changed to Made Object, E25
> changed to Made Feature and E71 changed to Made Thing.
>
> The “human” nature of the agent that does the making is explicit in the
> ontology, in that only humans or groups there-of can be Actors and carry
> out Productions or Creations, so there is no ambiguity about non-humans
> making these.
>
> This issue was discussed at length, and has been open in our profile’s
> tracker for 12 months now. We would greatly prefer that it be solved by
> changing the labels in the documentation, and thereby in the RDFS,
> rather than other RDF specific approaches such as minting new terms and
> using owl:sameAs to assert equality, or rebranding only in the JSON-LD
> serialization but persisting in other serializations. The change is
> consistent, reduces the length of the class names, and is an easy
> substitution. The comprehensibility of the label is still the same.
> Given the renaming of Collection to Curated Holding, migration of
> existing data has the same solution - just substitute the labels.
>
> As a second choice, if the above is not acceptable, we propose to
> instead replace “Man-“ with “Human-“ … only two additional characters,
> but a bit more of a mouthful.
>
> Many thanks for your engagement with this issue!
>
> Rob
>
>
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
This email and any attachments are intended solely for the addressee and may 
contain confidential information. If you are not the intended recipient of this 
email and/or its attachments you must not take any action based upon them and 
you must not copy or show them to anyone. Please send the email back to us and 
immediately and permanently delete it and its attachments. Where this email is 
unrelated to the business of University of the Arts London or of any of its 
group companies the opinions expressed in it are the opinions of the sender and 
do not necessarily constitute those of University of the Arts London (or the 
relevant group company). Where the sender's signature indicates that the email 
is sent on behalf of UAL Short Courses Limited the following also applies: UAL 
Short Courses Limited is a company registered in England and Wales under 
company number 02361261. Registered Office: University of the Arts London, 272 
High Holborn, London WC1V 7EY

___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.f

Re: [Crm-sig] wikidata (potential) use of cidoc crm terms

[Dominic Oldman]

yes,

we are doing this to a certain degree at BM with ResearchSpace.

Cheers,

D

On Sun, Jul 30, 2017 at 4:59 PM, Marco Neumann 
wrote:

> has someone looked into the use of CIDOC CRM terms in wikidata?
>
> I noticed a few similarities in the wikidata vocabulary to terms used
> in the CIDOC CRM.
>
> for example
>
>  beginning of existence (Q23956340)
>  https://www.wikidata.org/wiki/Q23956340
>
> with the following scope note:
>
>  class of events that cause the emergence of persistent items
>
> the item, a term used by wikidata, was created by Christopher H.
> Johnson a Researcher at the Akademie der Wissenschaften zu Göttingen
> on  1 May 2016‎ as a subclass of single event (Q29818016), itself a
> subclass of event (Q1190554).
>
> I think it is a good thing when wikidata authors make use of the
> Erlangen CRM or the CIDOC CRM respectively in the creation of the
> wikidata vocabulary / items but I equally would also like to
> "encourage" them to reference the use of the CIDOC CRM standard. last
> but not least to improve the quality of content on wikidata.
>
> I have observed the practice on wikidata to use the equivalent
> property (P1628) to establish the link to external URIs.
>
> e.g. instance of -> rdf:type
> https://www.wikidata.org/wiki/Property:P31
>
> what are your thoughts on this?
>
> best,
> Marco
>
>
> --
>
>
> ---
> Marco Neumann
> KONA
>
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>

Re: [Crm-sig] ISSUE: States and Situations

[Dominic Oldman]

Dear Rob, Martin

A Comment:

Dimension is defined as a measurable extent of any kind. This could be the
distance between two points on an object. I think this is the way it is
also described in the CRM reference, e.g. "This class comprises
quantifiable properties that can be measured by some calibrated means and
can be approximated by values, i.e. points or regions in a mathematical or
conceptual space..."

Skyscrapers tend to have different types of height dimension. For example,
height to tip (where there is a spire or needle), height to architectural
top, height to highest occupied floor. These are all different dimension
types measuring from one point to another on a building.

However, on the specific example, do I want to describe a state of
'openess' or am I just opening the lid to make it more convenient to
measure the different dimensions of the same box which really hasn't
changed  - height to top of closed lid, height to top of open lid. As
Martin mentions the box is specifically opened in order to take a
particular type of dimension measurement. The example of measuring these
dimensions without opening the lid at all e.g taking two measurements in a
closed position and adding them together) is also an important indicator
that we don't really need to get into a state and I expect for many fragile
items the measurement is done in this way - practically indicating that
this is simply a type of dimension.

I measured my tea caddy this morning. I measured with the "lid on" to the
point where the lid starts and then again to the top of the lid. I then
took the lid off and measured the main body of the caddy again. It was the
same measurement as when the lid was on! It is the same caddy and the
measurement was not affected. When I took the lid off it didn't really
change the properties particularly.  The two measurements, one to the top
of the main caddy body and one to the top of the lid are two different
dimensions of the same thing, like the skyscraper. If the caddy was made of
wood then these measurements might change in different conditions like, for
example, heat and humidity compared to freezing conditions. In this case
the same dimensions might have a different result but that would be a
different situation.

If I could only measure a dimension on the bottom of the box by turning the
box over, is this a dimension of a particular state (i.e. upside down
state)? - perhaps in common usage but this isn't the same as the context we
talk about.

I agree that the world is constantly changing (and our understanding of it
changes). However, taking a slightly different line, it is not necessary,
in my opinion, to be exhaustive in order to describe a valid and useful
type of totality. Some things are more useful than others. I would
therefore agree that we need to be careful about the use of states as this
could have quite problematic implications for which, as Martin says, we are
not equipped to deal with and technology hasn't really helped with (perhaps
made worse), but in any event we don't need.

I think we should update the definition of S16 - its a bit thin but I think
it could be updated to a better state. :-)

D


































orcid.org/-0002-5539-3126

On Tue, Apr 11, 2017 at 6:37 PM, Robert Sanderson 
wrote:

>
> As in physics, you can know either the state of objects in the universe or
> the forces that act upon them, but never both (  The proposal takes the
> former as more valuable for the work that we are attempting to do –
> describe the state of objects in our care either for conservation purposes
> or for simple descriptive purposes. The CRM seems to try to model the
> ephemeral forces, to the exclusion of the things being acted upon.
>
> By which I mean that E11 Modification enables the description of the
> transforming force (the opening of the lid) but does not allow the
> identification of the resulting state.
>
> _:LidOpening a Modification ;
> has_type  ;
> has_modified  ;
> carried_out_by  ;
> had_specific_purpose _:measurement1, _:measurement2 ;
> has_timespan  .
>
> _:measurement1 a Measurement ;
> measured  ;
> observed_dimension _:height .
>
> _:height a Dimension ;
> has_type  ;
> has_value 20 ;
> has_unit  .
>
> _:measurement2 a Measurement ;
> measured  ;
> observed_dimension _:width .
>
> _:width a Dimension ;
> has_type  ;
> has_value 15 ;
> has_unit  .
>
> We have described the forces … the actions … of lid-opening and measuring,
> and linked the observed dimensions … but nowhere is there an entity that IS
> the box with its lid open.  We need to understand the LidOpening action’s
> purpose in order to deduce that the measurements, although they are of the
> box, pertain to some un-identified state of that object. We do not have
> anywhere to associate even a label “Box with Lid Open” with those
> measurements.
>
> We would not want to say that the opening of the lid somehow destroyed
> B

Re: [Crm-sig] ISSUE: States and Situations

[Dominic Oldman]

Hi Rob,

...and this is the problem that CRM addresses. This is the problem that
everyone uses different vocabularies which has made it difficult for us to
integrate data. In contrast, CRM creates a semantic framework of entities
for integration. The incorporation of vocab through E55 is a solution,
often far better than that actually used in collection management systems
that prioritise vocabularies. In a CMS we simply pick a vocabulary term
from an authority to populate a field. In other words we implicitly use P2
with authority terms and we add no framework semantics to the field value
pairs. e.g. Field:Dimension, Value:height,  or for the BM and others, a
field label that is hard to decipher.

In CRM, Dimension is explicitly typed and the vocabulary attached to it is
typed as Type -  we make use of skos through E55 Type (or skos:Concept) -
which is a good place for vocabulary. If you incorporated vocabulary terms
into the ontology itself then you would simply create the unmaintainable
schema that CRM was created to solve. P2 is far better than having
specialised vocabulary based properties. We sometimes specialise P2 in rare
occasions with a property associated with a particular vocabulary term
which is a one off - perhaps to differentiate types applied to the same
domain.

When we applied specialisation to internal vocabularies (in particular,
association vocabulary)  we realised that it led to a problem in which the
vocabulary started to dominate the ontology schema (large numbers of
specialisation of P2 has type) and make it unsupportable without any
benefits over and above - P2_has_type >E55 (skos:Concept) > skos:prefLabel.
The specialised properties we created from the vocabularies served no
practical purpose when comparing vocabulary terms and probably made matters
worse. I am happy to send some early examples of this.

In comparison in many base systems I see, the additional vocabulary is not
even normalised and resides in the same field  - something like 20 x 10
(open) or (open lid) or some other vocabulary term. If you look at the
Met's recent public data you will see that that have variations of
dimension with descriptions in brackets. I think sometimes these are
physical features, but appear like this,  Dimension: 30H x 10W (base); 20 x
5 (clock face) - and so on.  Dimension type, value, unit and additional
type reflects CDWA (except with semantics), but in CDWA the only mandated
field is "dimension description" (free text).

Vocabulary alignment is a separate issue but actually made a little easier
by employing a CRM framework first.

Best,

Dominic

orcid.org/-0002-5539-3126

On Mon, Apr 3, 2017 at 8:35 PM, Robert Sanderson 
wrote:

> Thanks Martin :)
>
> If I understand correctly, both the type of dimension (height vs width)
> and the state of the object being measured (lid-open vs lid-closed) would
> both end up as external P2_has_type URIs?
>
> _:h a Dimension ;
>   label “Height of the box with the lid open” ;
>   has_type  ,  ;
>   has_value 14 ;
>   has_unit  .
>
> And as the width doesn’t change depending on  or 
> ness:
>
> _:w a Dimension ;
>   label “Height of the box with the lid open” ;
>   has_type  , ,  ;
>   has_value 8 ;
>   has_unit  .
>
> It seems a little jarring to have a core museum activity being treated
> with (from my perspective) little regard, compared to some of the existing
> distinctions made between classes with very little practical value. When
> the  and  URIs are not understood, let alone the unit
> URI, the only thing the ontology actually captures is the value… and as E60
> can be a string, there’s not all that much value (ha!) there either.
>
> When the answer to all questions is “Just put it in P2”, doesn’t that give
> one pause that P2 is so broad as to be meaningless?
>
> Rob
>
>
> On 4/3/17, 12:16 PM, "martin"  wrote:
>
> Dear Robert,
>
> The standard way to describe this in the CRM is to type the Dimension
> with the procedure:
> a) Lid-open
> b) Lid-closed
>
> The Measurement procedure type can be documented by a detailed text.
>
> In biology, one would measure "wingspan at life" and "winspan dead" of
> a
> bird, etc.
>
> Best,
>
> martin
>
> On 3/4/2017 7:13 μμ, Robert Sanderson wrote:
> > Dear all,
> >
> > One of our use cases which we are having trouble modeling with just
> the core CRM ontology is measurements of an object in a particular state.
> For example, we would like to record the measurements of a chest with the
> lid open, rather than those with the lid closed.  It is the same object,
> just in two different states, resulting in different measurements.
> >
> > The proposed scope note does certainly clarify more than the rather
> terse original, but if there is any feedback or guidance as to the above
> situation, we would be greatly appreciative.
> >
> > Many thanks,
> >
> > Rob
> >
>
> --
>
> 

[Crm-sig] Fwd: Re: Crm-sig Digest, Vol 122, Issue 8

[Dominic Oldman]

-- Forwarded message --
From: "Dominic Oldman" 
List-Post: crm-sig@ics.forth.gr
Date: 10 Mar 2017 6:03 p.m.
Subject: Re: [Crm-sig] Crm-sig Digest, Vol 122, Issue 8
To: "Martin Doerr" 
Cc:

Sure, that seems logical as in this case the part of expression is
arbitrary. I will submit an issue for a clarification in the scope note
between self contain expression and fragment and write draft submission.

Cheers,

Dominic

On 10 Mar 2017 5:40 p.m., "martin"  wrote:

> Dear Dominic,
>
> If you regard this as a new issue, or new evidence of an old one, please
> mark your message by "ISSUE", and it will be on the agenda. Every crm-sig
> member has the right to raise an issue.
>
> BTW, I agree that a "Page" is not a self-contained expression, but a
> fragment. In general, it does not intend to stop at meaningful
> propositional boundaries. It might be, that a self-contained expression is
> made to fit on one page. The levels of consideration are tricky: The
> scanned image as an expression in its own right (or better just Information
> Object?) incorporates but is not logically the same as the incorporated
> expression.
>
> best,
>
> martin
>
> On 10/3/2017 5:24 μμ, Dominic Oldman wrote:
>
> Hi Florian,
>
> Here is an off line discussion that we should have put on the list.
>
> Cheers,
>
> D
>
>
> orcid.org/-0002-5539-3126
>
> On Fri, Mar 10, 2017 at 12:47 PM, Christian-Emil Smith Ore <
> c.e.s@iln.uio.no> wrote:
>
>> Do so, and send my regards. Please incorproate the following example:
>>
>>
>> To create excerpts is common activity in lexicography and history. An
>> excerpt is indeed a fragement of a text. The  corresponding expression is a
>> fragment expression.  See for example a paperslip for the word 'shovelfork'
>> (used to prepare la (small) field instead of ploughing.  The text is a
>> fragment of a longer text dealing with somebody childhood memories
>>
>>
>> http://www.edd.uio.no/setelarkiv/setel1963769.jpg​
>>
>>
>> The entire paper slip represents a self-contained expression where a
>> expression fragment is incorporated (in the corresponding work)
>>
>>
>> Best
>>
>> Christian-Emil
>> --
>> *From:* Dominic Oldman 
>> *Sent:* 10 March 2017 13:32
>>
>> *To:* Christian-Emil Smith Ore
>> *Subject:* Re: [Crm-sig] Crm-sig Digest, Vol 122, Issue 8
>>
>> Hi Christian,
>>
>> I note that this didnt go on the list - Can I post this to the list as I
>> think it is important generally.
>>
>> D
>>
>> orcid.org/-0002-5539-3126
>>
>> On Fri, Mar 10, 2017 at 12:30 PM, Dominic Oldman 
>> wrote:
>>
>>> Although I think then the scope note could be much clearer on E23
>>> because it tends to suggest fragments isolated from the whole whereas in
>>> this case the section still resides within a whole. Although the scope note
>>> does state "excerpts" I still think this could be stated far more clearly
>>> with less ambiguity -  if it does mean that these excerpts can be
>>> identified sections of the information object within a whole text.
>>>
>>> Can we put this on the agenda for the next meeting?
>>>
>>> D
>>>
>>>
>>> orcid.org/-0002-5539-3126
>>>
>>> On Fri, Mar 10, 2017 at 9:37 AM, Christian-Emil Smith Ore <
>>> c.e.s@iln.uio.no> wrote:
>>>
>>>> It is not necessarily so that the text printed on a page is a
>>>> self-contained expression, it is in general a F23 Expression Fragment ​
>>>>
>>>>
>>>> Best
>>>>
>>>> Christian-Emil
>>>>
>>>>
>>>> F22 Self-Contained Expression
>>>>
>>>> This class comprises the immaterial realisations of individual works at
>>>> a particular time that are regarded as a complete whole. The quality of
>>>> wholeness reflects the intention of its creator that this expression should
>>>> convey the concept of the work. Such a whole can in turn be part of a
>>>> larger whole.
>>>>
>>>>
>>>> Inherent to the notion of work is the completion of recognisable
>>>> outcomes of the work. These outcomes, i.e. the Self-Contained Expressions,
>>>> are regarded as the symbolic equivalents of Individual Works, which form
>>>> the atoms of a complex work. A Self-Contained Expression may contain
>>>> ex

Re: [Crm-sig] Crm-sig Digest, Vol 122, Issue 8

[Dominic Oldman]

Hi Florian,

Here is an off line discussion that we should have put on the list.

Cheers,

D


orcid.org/-0002-5539-3126

On Fri, Mar 10, 2017 at 12:47 PM, Christian-Emil Smith Ore <
c.e.s@iln.uio.no> wrote:

> Do so, and send my regards. Please incorproate the following example:
>
>
> To create excerpts is common activity in lexicography and history. An
> excerpt is indeed a fragement of a text. The  corresponding expression is a
> fragment expression.  See for example a paperslip for the word 'shovelfork'
> (used to prepare la (small) field instead of ploughing.  The text is a
> fragment of a longer text dealing with somebody childhood memories
>
>
> http://www.edd.uio.no/setelarkiv/setel1963769.jpg​
>
>
> The entire paper slip represents a self-contained expression where a
> expression fragment is incorporated (in the corresponding work)
>
>
> Best
>
> Christian-Emil
> --
> *From:* Dominic Oldman 
> *Sent:* 10 March 2017 13:32
>
> *To:* Christian-Emil Smith Ore
> *Subject:* Re: [Crm-sig] Crm-sig Digest, Vol 122, Issue 8
>
> Hi Christian,
>
> I note that this didnt go on the list - Can I post this to the list as I
> think it is important generally.
>
> D
>
> orcid.org/-0002-5539-3126
>
> On Fri, Mar 10, 2017 at 12:30 PM, Dominic Oldman 
> wrote:
>
>> Although I think then the scope note could be much clearer on E23 because
>> it tends to suggest fragments isolated from the whole whereas in this case
>> the section still resides within a whole. Although the scope note does
>> state "excerpts" I still think this could be stated far more clearly with
>> less ambiguity -  if it does mean that these excerpts can be identified
>> sections of the information object within a whole text.
>>
>> Can we put this on the agenda for the next meeting?
>>
>> D
>>
>>
>> orcid.org/-0002-5539-3126
>>
>> On Fri, Mar 10, 2017 at 9:37 AM, Christian-Emil Smith Ore <
>> c.e.s@iln.uio.no> wrote:
>>
>>> It is not necessarily so that the text printed on a page is a
>>> self-contained expression, it is in general a F23 Expression Fragment ​
>>>
>>>
>>> Best
>>>
>>> Christian-Emil
>>>
>>>
>>> F22 Self-Contained Expression
>>>
>>> This class comprises the immaterial realisations of individual works at
>>> a particular time that are regarded as a complete whole. The quality of
>>> wholeness reflects the intention of its creator that this expression should
>>> convey the concept of the work. Such a whole can in turn be part of a
>>> larger whole.
>>>
>>>
>>> Inherent to the notion of work is the completion of recognisable
>>> outcomes of the work. These outcomes, i.e. the Self-Contained Expressions,
>>> are regarded as the symbolic equivalents of Individual Works, which form
>>> the atoms of a complex work. A Self-Contained Expression may contain
>>> expressions or parts of expressions from other work, such as citations or
>>> items collected in anthologies. Even though they are incorporated in the
>>> Self-Contained Expression, they are not regarded as becoming members of the
>>> expressed container work by their inclusion in the expression, but are
>>> rather regarded as foreign or referred to elements.
>>>
>>>
>>> F22 Self-Contained Expression can be distinguished from F23 Expression
>>> Fragment in that an F23 Expression Fragment was not intended by its creator
>>> to make sense by itself. Normally creators would characterise an outcome of
>>> a work as finished. In other cases, one could recognise an outcome of a
>>> work as complete from the elaboration or logical coherence of its content,
>>> or if there is any historical knowledge about the creator deliberately or
>>> accidentally never finishing (completing) that particular expression. In
>>> all those cases, one would regard an expression as self-contained.
>>>
>>>
>>> --
>>> *From:* Dominic Oldman 
>>> *Sent:* 09 March 2017 20:50
>>> *To:* Christian-Emil Smith Ore
>>>
>>> *Subject:* Re: [Crm-sig] Crm-sig Digest, Vol 122, Issue 8
>>>
>>>
>>> So in this case the self contained expression (information object)
>>> identified as page 1 can then be represented by a part of a PDF image which
>>> itself identifies parts (a physical page?) which are identified accordingly.
>>>
>>> I'm still not su

Re: [Crm-sig] Crm-sig Digest, Vol 122, Issue 8

[Dominic Oldman]

Hi Florian,

Just trying to understand. 

You have an expression that is organised with page numbers. This is reproduced 
in the PDF. The expression page numbers are the same (the information object) 
but page 1 is spread over two carrier pages. i.e. page 1 is still page 1 as an 
information object but on the application adobe spreads it over two application 
carrier pages. Is that right? or is it something else. 

If the expression is the same (the same information object) then isn't page 1, 
page 1 

Can you clarify. 

D



From: Crm-sig [crm-sig-boun...@ics.forth.gr] on behalf of Florian Kräutli 
[fkraeu...@mpiwg-berlin.mpg.de]
Sent: 09 March 2017 10:38
To: crm-sig@ics.forth.gr
Subject: Re: [Crm-sig] Crm-sig Digest, Vol 122, Issue 8

Dear Martin,

many thanks for your input!

Our question at the moment is simply, does a page in the PDF represent one or 
two pages of the book?

Later on, we might have more specific questions that will require us to define 
the relationships between these two page identifiers (in the physical book and 
in the PDF) more explicitly. We would then also need to manually assess each 
PDF as, for instance, we can not assume that page n in a book corresponds to 
page n/2 in a double-spread PDF. A PDF might contain some additional pages with 
information about the digitisation process.

For now we however only need a binary answer: double-spread yes or no.

All the best,

Florian


> On 8 Mar 2017, at 11:00, crm-sig-requ...@ics.forth.gr wrote:
>
> Send Crm-sig mailing list submissions to
>   crm-sig@ics.forth.gr
>
> To subscribe or unsubscribe via the World Wide Web, visit
>   http://lists.ics.forth.gr/mailman/listinfo/crm-sig
> or, via email, send a message with subject or body 'help' to
>   crm-sig-requ...@ics.forth.gr
>
> You can reach the person managing the list at
>   crm-sig-ow...@ics.forth.gr
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Crm-sig digest..."
>
>
> Today's Topics:
>
>   1. Re: Pages reproduced as spreads (martin)
>
>
> --
>
> Message: 1
> Date: Tue, 7 Mar 2017 18:24:17 +0200
> From: martin 
> To: crm-sig@ics.forth.gr
> Subject: Re: [Crm-sig] Pages reproduced as spreads
> Message-ID: 
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Dear Florian,
>
> There is no model without a question. Pages of books constitute a
> partitioning of an
> information object. Each page number can be seen as an identifier.
> Paragraphs belong to an alternative partitioning system. The
> reproduction has its own particioning, the scanned double pages.
> Each scanned image represents, actually also incorporates, the text of
> two pages of the reproduced.
> Between alternative partitionings, one can define includes/overlaps
> relations.
>
> If this is elegant, depends on what queries or functions you'd like to
> support.
>
> Best,
>
> martin
>
> On 7/3/2017 1:36 ??, Florian Kr?utli wrote:
>> Dear all,
>>
>> I have a collection of Books (F5) that have been reproduced (F33) as PDFs 
>> (E84).
>> In some cases, books have been digitised as spreads i.e. one page in the PDF 
>> represents two pages in the book.
>>
>> Is there an elegant way to model this?
>>
>> Best,
>>
>> Florian
>> ___
>> Crm-sig mailing list
>> Crm-sig@ics.forth.gr
>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>
>
>
> --
>
> --
>  Dr. Martin Doerr  |  Vox:+30(2810)391625|
>  Research Director |  Fax:+30(2810)391638|
>|  Email: mar...@ics.forth.gr |
>  |
>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   |
>  |
>  Web-site: http://www.ics.forth.gr/isl   |
> --
>
>
>
> --
>
> Subject: Digest Footer
>
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>
> --
>
> End of Crm-sig Digest, Vol 122, Issue 8
> ***


___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] 6.2.2's MonetaryAmount and Currency

[Dominic Oldman]

Happy new year!

Just preparing to go back to work next week and saw this thread.

>From my quick reading of the emails it is of course possible to place a
time span on any event/activity such as a measurement event and connect
that to a dimension that has a P2_has_type (height, width, US inch, US inch
(pre-1959), Swedish inch, etc and a P90 value and P91 unit.

Our own mapping uses P2_has_type to provide the type of dimension of an E54
and then uses a vocabulary (E55) provided by qudt http://www.qudt.org/ (or
local vocab for more specialized dimension types not available in qudt). We
also use qudt for unit but again you can add your own historic ones - e.g.

On a more general data integration point I was interested in Rob's email
about the pre-1959 inch and looked it up. I assume that Rob has the data
that provides a date of each measurement activity, and that all inch's are
US and that those actors who did the original measuring adhered to the
different inches at the exact time of change in 1959. I know that in
Britain we might have been less than quick at changing to new fancy EU
measurements and distributing new rulers! and in any event changing
measurements is usually transitional (the Swedish inch was transitioned
between 1855 and 1863 - quite an efficient eight years). It seems that more
generally in history the inch has been less than a standard. If the purpose
is to query or construct triples that provide consistent metric
conversions, for example, then the more diverse the integrated data (our
primary aim is to integrated diverse data) the more complex it becomes. On
wiki media (and wikipedia) they have the following image.
https://en.wikipedia.org/wiki/Inch#/media/File:Inch_converter.jpg. I cite
http://themetricmaven.com/ from which I have derived the information for
this email and which is devoted to US metric system and its history. The
site author has also published a book called

"The Dimensions of the Cosmos: Tales from 16 Metric Worlds" (by Randy
Bancroft) described as follows,

"Originally, our world was described using a plethora of provincial ad hoc
measurement units only of everyday dimensions. The US inch was initially
defined as the length of three barleycorn placed end-to-end, and is the
current basis of US shoe sizes. The invention of the microscope and
telescope in the 17th century revealed unimagined new macroscopic and
microscopic worlds. The Dimensions of the Cosmos takes the reader on a tour
of these hidden worlds with the only measurement system designed to
intuitively describe them, the modern metric system."

>From the wiki media image the metric maven site reproduces the following
table. It should also be noted that the Swedish inch also changed in the
later part of the 19th century and please note the large variation
particularly for the Russian inch.



   - Hamburgh – Inch divided into 8 parts. 1 inch ≈ 23.2 mm
   - Austrian – Inch divided into 8 parts. 1 inch ≈ 25.8 mm
   - Itallian – Inch divided into 8 parts. 1 inch ≈ 28.3 mm
   - Bremen – Inch divided into 10 parts. 1 inch ≈ 23.7 mm
   - Swedish – Inch divided into 12 parts. 1 inch ≈ 24.3 mm
   - Turkish – Inch divided into 12 parts. 1 inch ≈ 31.3 mm
   - Bavarian – Inch divided into 12 parts. 1 inch ≈ 24.0 mm
   - Spanish – Inch divided into 12 parts. 1 inch ≈ 23.0 mm
   - Portuguese – Inch divided into 12 parts. 1 inch ≈ 27.0 mm
   - Moscow – Inch divided into 12 parts. 1 inch ≈ 27.7 mm
   - Russian – Inch divided into 8 parts. 1 inch ≈ 44.1 mm
   - Amsterdam – Inch divided into 12 parts. 1 inch ≈ 23.5 mm
   - Rhynland – Inch divided into 12 parts. 1 inch ≈ 26.1 mm
   - French – Inch divided into 12 parts. 1 inch ≈ 27.0 mm
   - Fr. Metre – Centimetres divided into millimetres
   - English – Inch divided into 32 parts. 1 inch ≈ 25.3 mm

I will pass this on to our own documentation section for their comment.

Although obviously important from an institutional documentation point of
view, I agree with Martin in that when you are exploring integrated
datasets you probably don't want to rely on dimension values as the main
exploration mode and we are instead looking at how best to display
dimensions as facets once the result set is reduced to a more useful graph
using more global categories. The interfaces that FORTH and BM are
currently working on do precisely this and we are both at a stage trying to
understand what relationships work best at the more macro level and what
information is better left at a facet or micro (record) level. For my own
part this data is often (whatever the dataset) affected by varying
standards and inconsistent validation over time, and so attempting to
provide faceted dimension ranges (which might be useful to users at another
level of exploration) becomes difficult, but at the moment, given current
feedback probably makes this marginal work at the moment. However, I do
hope to be able to provide CRM-SIG with some practice information at some
point.

On this point we have made our beta expl

Re: [Crm-sig] Associative relationship mapping / Cidoc-CRM Top Property

[Dominic Oldman]

My apologies to Phil! I found it but it was not quite as interpreted.

It comes from a document in 2012 and was a particular specialisation of a
database association code and not intended as a general relationship
property (there is no scope note etc). Just about all the specialisations
that we did in our early naive days of using CRM were deleted and are now
used simply as vocabularies to type particular entities.

Hope this make sense. I suspect that the old wiki site should be removed
from the Web.

Cheers,

D











orcid.org/-0002-5539-3126

On Fri, Sep 23, 2016 at 8:34 AM, Merz, Dorian  wrote:

> Dear All,
>
> It would be pleasing to have a kind of P0_CRM_top_property or
> PX_is_related_to as the "mother of all properties" in the CRM. This would
> in no way interfere with the semantics of the other properties while
> providing us with some ways to solve semingly trivial practical problems
> like finding all CRM-Properties in an rdf or owl implementation or being
> able to say that two objects/individuals/entities are in relation but we
> don't know exactly how, etc.
> Such property would resemble the owl-top-property but keep compatibility
> with the CRM. Domain and Range should, of course, be E1
> I feel that this is not exactly the "is related to" property that was
> discussed here earlier but probably it is still being worth discussion.
>
> kind regards,
> Dorian
>
>
> Dipl.-Inf. Dorian Merz
> Univ. Erlangen-Nuernberg
> Department Informatik
> AG Digital Humanities
> Konrad-Zuse-Str. 3-5
> 91052 ERLANGEN
>
> Raum 00.046
> Fon: +49 9131 85 29095
> Mail: dorian.merz AT fau.de
> --
> *Von:* Crm-sig [crm-sig-boun...@ics.forth.gr]" im Auftrag von "martin [
> mar...@ics.forth.gr]
> *Gesendet:* Donnerstag, 22. September 2016 19:56
> *An:* Simon Spero
> *Cc:* crm-sig@ics.forth.gr
> *Betreff:* Re: [Crm-sig] Associative relationship mapping
>
> On 22/9/2016 8:48 μμ, Simon Spero wrote:
>
> If the CRM is  interpreted as an OWL ontology, then the most general
> relationship between  two objects is *owl:topObjectProperty. *
>
> This property has very weak semantics (e.g. that there is some known
> relationship between a and b).
>
> One benefit / problem with using this property is that it is a super
> property of all object properties, so you may need to be careful to turn
> inference on / off.
>
> You can also define your own equivalent placeholder, which will make it
> easier to use inference when you can start upgrading to more specific
> relationships.
>
> Simon
>
> Sounds like a good solution! It is standard, and obviously less committed
> than anything in the CRM...
>
> Martin
>
>
> --
>
> --
>  Dr. Martin Doerr  |  Vox:+30(2810)391625|
>  Research Director |  Fax:+30(2810)391638|
>|  Email: mar...@ics.forth.gr |
>  |
>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   |
>  |
>  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] Associative relationship mapping

[Dominic Oldman]

This is intriguing.

I've never used the property, PX_is_related_to or PXX_is_related_to myself
and it isn't in any of my documentation. I have checked my BM mapping
manual (361 pages) and the only mention of "related to" is a BM production
association code for which the semantics have been ascertained and mapped
to core CRM properties. Additionally when you attempt to use it in a query
on the BM Endpoint, it does not exist in any record instance. See

http://collection.britishmuseum.org/sparql?sample=PREFIX+bmo%3A+%3Chttp%3A%2F%2Fcollection.britishmuseum.org%2Fid%2Fontology%2F%3E%0D%0APREFIX+rso%3A+%3Chttp%3A%2F%2Fwww.researchspace.org%2Fontology%2F%3E%0D%0Aselect+*%0D%0A%7B%0D%0A%3Fa++bmo%3APX_is_related_to+%3Fb%0D%0A%7D

for PX_is_related_to

or

http://collection.britishmuseum.org/sparql?sample=PREFIX+bmo%3A+%3Chttp%3A%2F%2Fcollection.britishmuseum.org%2Fid%2Fontology%2F%3E%0D%0APREFIX+rso%3A+%3Chttp%3A%2F%2Fwww.researchspace.org%2Fontology%2F%3E%0D%0Aselect+*%0D%0A%7B%0D%0A%3Fa++bmo%3APXX_is_related_to+%3Fb%0D%0A%7D

for PXX_is_related_to

I've also had a look at the turtle ontology file containing our extensions
and cant find it. It is possible I suppose that someone decided to add
something like this (and if so mistakenly) at some point , but I have no
recollection of it  - or perhaps someone else created it based on the BM
extension convention and I wonder if that is where the extra X came from.
PX stands for Property Extension (used by BM)  - I'm not sure what PXX is -
it would certainly be interesting to know its origins. However,  Martin is
of course right, both in terms of theory and practice, regardless of where
it originated from.

D







orcid.org/-0002-5539-3126

On Thu, Sep 22, 2016 at 6:56 PM, martin  wrote:

> On 22/9/2016 8:48 μμ, Simon Spero wrote:
>
> If the CRM is  interpreted as an OWL ontology, then the most general
> relationship between  two objects is *owl:topObjectProperty. *
>
> This property has very weak semantics (e.g. that there is some known
> relationship between a and b).
>
> One benefit / problem with using this property is that it is a super
> property of all object properties, so you may need to be careful to turn
> inference on / off.
>
> You can also define your own equivalent placeholder, which will make it
> easier to use inference when you can start upgrading to more specific
> relationships.
>
> Simon
>
> Sounds like a good solution! It is standard, and obviously less committed
> than anything in the CRM...
>
> Martin
>
>
> --
>
> --
>  Dr. Martin Doerr  |  Vox:+30(2810)391625|
>  Research Director |  Fax:+30(2810)391638|
>|  Email: mar...@ics.forth.gr |
>  |
>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   |
>  |
>  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] E82 Actor Appellation Issue

[Dominic Oldman]

If an appellation is attached to an actor - isn't it an actor appellation.
Likewise if an appellation is attached to a place then isn't it a place
appellation?

orcid.org/-0002-5539-3126

On Thu, Aug 4, 2016 at 4:20 PM, Paul Cripps 
wrote:

> Just to second Franco, it is important to recognise place names as a
> specialisation of appellations using E44 as this facilitates links to other
> place based resources (eg via Ordnance Survey Linked Data URIs)
>
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>

Re: [Crm-sig] E82 Actor Appellation Issue

[Dominic Oldman]

I was under the impression from some time ago that this was going to be
retired. An appellation of an actor entity is an actor appellation and
doesnt need specialisation.

D





orcid.org/-0002-5539-3126

On Tue, Aug 2, 2016 at 9:30 AM, Stephen Stead  wrote:

> The scope note and examples of E82 Actor Appellation do not clearly convey
> the idea that the appellation must be of a form that is characteristically
> an appellation of an actor. This is causing confusion in the user community.
>
> One alternative is to retire E82 altogether and the other is to update the
> scope note.
>
> I would vote for deprecation/retirement.
>
>
>
> I have also suggested a new scope note and changed examples:-
> E82 Actor Appellation
>
> Subclass of: E41 <#m_-7536294752194596537__E41_Appellation>
> Appellation
>
>
>
> Scope note:This class comprises any sort of name, number, code or
> symbol characteristically used to identify an E39 Actor.
>
>
>
> An E39 Actor will typically have more than one E82 Actor Appellation, and
> instances of E82 Actor Appellation in turn may have alternative
> representations. The distinction between corporate and personal names,
> which is particularly important in library applications, should be made by
> explicitly linking the E82 Actor Appellation to an instance of either E21
> Person or E74 Group/E40 Legal Body. If this is not possible, the
> distinction can be made through the use of the *P2 has type* mechanism.
>
> Examples:
>
> §  “John Doe”
>
> §  “Doe, J”
>
> §  “the U.S. Social Security Number 246-14-2304”
>
> §  “the Artist Formerly Known as Prince”
>
> §  “the Master of the Flemish Madonna”
>
> §  “Raphael’s Workshop”
>
> §  “the Brontë Sisters”
>
> §  “ICOM”
>
> §  “International Council of Museums”
>
>
> E82 Actor Appellation
>
> Subclass of: E41 <#m_-7536294752194596537__E41_Appellation>
> Appellation
>
>
>
> Scope note:This class comprises any sort of name, number, code or
> symbol characteristically used to identify an E39 Actor. That is the very
> form of the name indicates that it is an appellation of an instance of E39
> Actor.
>
>
>
> An E39 Actor will typically have more than one E82 Actor Appellation, and
> instances of E82 Actor Appellation in turn may have alternative
> representations. The distinction between corporate and personal names,
> which is particularly important in library applications, should be made by
> explicitly linking the E82 Actor Appellation to an instance of either E21
> Person or E74 Group/E40 Legal Body. If this is not possible, the
> distinction can be made through the use of the *P2 has type* mechanism.
>
> Examples:
>
> §   the U.S. Social Security Number “246-14-2304”
>
> §  UK Company Number “2374216”
>
> §  Leonardo da Vinci’s ULAN identifier “ULAN500010879”
>
>
>
> Rgds
>
> SdS
>
>
>
> Stephen Stead
>
> Director
>
> Paveprime Ltd
>
> 35 Downs Court Rd
>
> Purley, Surrey
>
> UK, CR8 1BF
>
> Tel +44 20 8668 3075
>
> Fax +44 20 8763 1739
>
> Mob +44 7802 755 013
>
> E-mail ste...@paveprime.com
>
> LinkedIn Profile http://uk.linkedin.com/in/steads
>
>
>
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>

Re: [Crm-sig] How to represent the textual content of documents about museum objects?

[Dominic Oldman]

 Dear Conal,
I think there are various approaches you can take depending upon what your 
objectives are.
1. Identify (describe) the document and provide access to it. Using CRM this 
would harmonise with other CRM data.2. Identify particular fragments of the 
text (using FRBRoo).  3. Tag particular things in the text
In terms of 3 there is TEI but also the option of using CRM in RDFa tags to 
identify entities and relationships in the text that would have correspondence 
in the data. This is an approach we have used at the BM. RDFa tags can be used 
to identify people, places, subjects etc, and can link these entities using CRM 
properties. These can operate on their own as an extension to the RDF store or 
be harvested into the RDF store.

Cheers,
Dominic




 

 On Tuesday, 8 September 2015, 6:05, Conal Tuohy  
wrote:
   

 I have recently made an experimental software application to generate a Linked 
Data expression of Museum Data from the public collection API of Museum 
Victoria (Melbourne, Australia).

The Museum Victoria API is a custom-built web application which returns custom 
JSON data. My experimental software is a proxy which translates their JSON into 
RDF/XML using the Erlangen OWL version of the CIDOC CRM. More details available 
here: http://conaltuohy.com/blog/lod-from-custom-web-api/

The Museum Victoria database contains a number of "articles" which each 
describe one or more objects in their collection. I have modelled each of these 
as an "E31 Document", and related them to the corresponding collection items 
using "P70 documents". 

My question is how to express the text of the actual articles (which the Museum 
Victoria API provides as an HTML fragment embedded in its JSON response). At 
the moment I have simply used rdf:value to attach the HTML fragment as an XML 
literal to the E31 Document instance. Is this the recommended practice?

Here is an example of one of these "articles":
http://graphite.ecs.soton.ac.uk/browser/?uri=http%3A%2F%2Fconaltuohy.com%2Fxproc-z%2Fmuseum-victoria%2Fresource%2Farticles%2F1201

Regards

Conal




-- 
Conal Tuohy
http://conaltuohy.com/
@conal_tuohy
+61-466-324297

___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Why #TEI P5 as format-of-record for #cidocCRM Definition document

[Dominic Oldman]

It seems the right thing to do to spend some time on this to reduce FORTH's 
costs here.

That should be a core requirement.

D 


From: Crm-sig [crm-sig-boun...@ics.forth.gr] on behalf of Sebastian Rahtz 
[sebastian.ra...@it.ox.ac.uk]
Sent: 17 May 2015 16:02
To: martin
Cc: crm-sig@ics.forth.gr
Subject: Re: [Crm-sig] Why #TEI P5 as format-of-record for #cidocCRM Definition 
document

Sorry, Martin, I was not meaning to criticize at all. I hope it didn’t come 
over like that.

My reflections on this come from an interest in how
software and similar communities work; I have spent the last few decades hanging
out in the complex mini-worlds of TeX and of TEI, and its fascinating to see 
the similarities
between them and the CRM.

...
> Please do understand me right. We do all these services for free. None of 
> this is because we would defend
> jobs or technology.  Everything we do is a big concern, not a slight one;-) . 
> Everything better costs again. We need funding for each migration:-( .
>
absolutely understood. I was not using proprietary in a  critical sense. my 
concern is that
the future of the CRM is compromised if there are any technology barriers to 
people working
on it, and (for example) talking over the maintenance if FORTH lose interest.,

...
> The process, operations are complex and need control. XML is not a database, 
> it does not have functions. Of course you can put in in XML, and then use an 
> XML database on top to do the operations.
> It does not help you running IsA constraints on classes and properties, and 
> trigger sequences of changes.
> That needs code.

it does. but I wouldn’t distinguish so much between the XML representation of 
the source and the XML representation
of the functions. not the implementing the functions doesnt need code itself, 
of course.

I am thinking of the way an XML representation of a schema can embed all sorts 
of rules and constraints in the
form of Schematron. in another world, you’ll call that code, I call it part of 
the spec.


>> forgive me, but this looks like a tail wagging a dog :-}
> Well, forgive me also, what is the dog: The application S/W or the data 
> structure ;-) ?
> If the search and update operations are simple, a data structure may be the 
> dog.
> Otherwise;-)

true :-}

> If anybody is seriously interested, we can send the complete requirements 
> analysis.
> Then we can make together checklists what the benefits are.
can you expand? the requirements analysis for what?

> …..
> If we may go out of this business some day, nobody will be able to continue 
> the
> process as it stands now.
>
precisely, that’s what interests me. how you get to a setup which any 
reasonably IT-literate person
around the world can replicate, and take over the CRM in the (highly unlikely!) 
event that
a Grexit causes FORTH to go bankrupt.

Sebastian Rahtz
Chief Data Architect
University of Oxford IT Services
+44 1865 283431






___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Why #TEI P5 as format-of-record for #cidocCRM Definition document

[Dominic Oldman]

I am glad I asked. :-)

I agree with Sebastian. 
What I meant was - don't you consider the requirements first before 
implementing the solution - a key principle of the CIDOC CRM an any other 
project that might utilise a technology. 
In other words the usual approach is to understand the process and requirements 
first (and that is not just the requirements and processes of CRM SIG members) 
and then choose the appropriate implementation. Not choose the technical 
implementation first and then think about the requirements and user needs 
afterwards.
Requirement 1. We need to structure the document to make it easier to manage 
and maintain?Requirement 2. We need interchange with other TEI documents? 
Requirement 3. We need accessible interfaces for non-technologists for find CRM 
entities and relationships and also useful patterns of entities and 
relationships ?Requirement 4etc, etc
D
 


 On Sunday, 17 May 2015, 11:24, Sebastian Rahtz 
 wrote:
   

 #yiv1256237994 #yiv1256237994 _filtered #yiv1256237994 
{font-family:Wingdings;} _filtered #yiv1256237994 {} _filtered #yiv1256237994 
{font-family:Calibri;} _filtered #yiv1256237994 
{font-family:Consolas;}#yiv1256237994 p.yiv1256237994MsoNormal, #yiv1256237994 
li.yiv1256237994MsoNormal, #yiv1256237994 div.yiv1256237994MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;color:black;}#yiv1256237994 
a:link, #yiv1256237994 span.yiv1256237994MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv1256237994 a:visited, #yiv1256237994 
span.yiv1256237994MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv1256237994 pre 
{margin:0in;margin-bottom:.0001pt;font-size:10.0pt;color:black;}#yiv1256237994 
p.yiv1256237994MsoListParagraph, #yiv1256237994 
li.yiv1256237994MsoListParagraph, #yiv1256237994 
div.yiv1256237994MsoListParagraph 
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:12.0pt;color:black;}#yiv1256237994
 span.yiv1256237994HTMLPreformattedChar 
{font-family:Consolas;color:black;}#yiv1256237994 
span.yiv1256237994EmailStyle20 {color:#1F497D;}#yiv1256237994 
.yiv1256237994MsoChpDefault {font-size:10.0pt;} _filtered #yiv1256237994 
{margin:1.0in 1.0in 1.0in 1.0in;}#yiv1256237994 ol 
{margin-bottom:0in;}#yiv1256237994 ul {margin-bottom:0in;}#yiv1256237994 It 
seems to me self-evident that the CRM should be managed as an information 
resource (ie as a structured XML file) instead of a word-processor 
presentational document. And if its going to be in XML, I'd agree that TEI is 
the obvious format to choose since it is already used for literate programming, 
and has a lot of the necessary elements and semantic constructs, and tools, all 
in space. It is not insignificant that the TEI is aligned with the CRM in that 
its interested in digital cultural heritage, and that the TEI is consciously 
interested in the relationship between its world and the CRMs.
However,  I would like to hear more from Martin or whoever on how the CRM is 
authored at the moment. What is the master copy,  how is it managed, what are 
the tools used and/or needed by the editors? is the appearance of being a large 
Word document actually right?
As the author/maintainer of much of the TEI processing software (including 
OxGarage which Jim mentioned) and thechief designer of its current meta 
language, I can fairly lay claim to being someone who understands the 
implications :-}Nothing would make me happier [1] than helping transform the 
CRM master into a beautiful TEI XML file, if thereis sufficient interest.
[1] thats not actually true. I have a long list.

Sebastian Rahtz    Chief Data ArchitectUniversity of Oxford IT Services


___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] #cidocCRM SIG Mtg, new cidoc-crm.org website, & self & @FactMiners etc. introduction

[Dominic Oldman]

Hi Jim,
Your email is very densely populated. Just to summarise:
You are proposing: 
1. To help build a new CIDOC CRM web site.2. To create a method of producing 
the CIDOC CRM reference document in TEI format. 3. That we use the hashtag 
#cidocCRM for social networking. 
Is that correct?
Thanks,

Dominic
P.S. BTW why TEI?  (Apologies in advance to TEI enthusiasts! :-))    


 On Wednesday, 13 May 2015, 21:16, Jim Salmons  
wrote:
   

 Hello 
CIDOC CRM SIG Members,My name is Jim Salmons and my inter-related Citizen 
Science/History projects are @FactMiners (www.FactMiners.org) and @SoftalkApple 
(www.SoftalkApple.com).We are working on two inter-related applied research 
initiatives; #cidocCRMgraph and #cidocCRMdev, as briefly introduced here: 
http://goo.gl/XZKkCE. For links to related #cidocCRM posts expressing our 
interests/insights, please see: http://goo.gl/dpbhPs.BACKGROUND INFOFor our 
most complete “manifesto” of applied research interests, please see: 
https://goo.gl/3Vb0lO contributed and accepted into the CODE|WORDS series, and 
this GraphGist Edition of my #MCN2014 presentation: http://goo.gl/gS2FJk 
(especially the 2nd half of the embedded video which introduces, but does not 
dive too deeply into, our FactMiners #cidocCRM focus). And for some context and 
link to an unfolding #cidocCRM-related conversation at Schema.org in which I am 
trying to inject a metamodel-driven design POV, please see: 
http://goo.gl/x1DSAB. (Also, I am fortunate to have, and personally thank, the 
members of my #cidocCRM/#TEI Personal Learning Network who are helping me to 
fast-track my knowledge about the #cidocCRM and #TEI: 
https://goo.gl/skvhaj.)CRM SIG MTG – NEW WEBSITE ITEM INTEREST & RECOMMENDATION 
FOR TEI P5 FORMAT FOR DEFINITION DOCUMENTAs to the upcoming CRM SIG meeting 
agenda item for next Friday morning to discuss a new cidoc-crm.org website, 
please note that @FactMiners has a long-standing public “hand raised” to either 
lead or contribute to this much-needed community project. If this is an open 
issue and the project’s nature and goals are to be determined through next 
Friday’s discussion, I would recommend that the new website be built 
HAND-IN-HAND with adopting TEI P5 as the semantic “format of record” for the 
CIDOC CRM Definition document. (MS-Word and PDF just won’t cut it moving 
forward when both humans and our software agents need equal access to this 
foundation document.)While there are those who prefer/need an RDF encoding, 
there will be a growing group of folks like @FactMiners who will be best served 
by a human- and machine-readable edition of the Definition document “as is” 
without a complicated graph transformation applied (that can only further 
obfuscate existing graph-interpretation issues of the current state of the 
model). A TEI P5 encoding of the Definition document would not just be useful 
in its own right, but it could figure into an efficient workflow for the SIG in 
the future whereby the official public-facing website would be generated from 
(and updated by) releases of the official #TEI Definition document.If the SIG 
would prefer not to select a particular lead or other sanctioned “official 
project” of the SIG, I would ask that you simply consider taking the existing 
cidoc-crm.org website and put it into a public GitHub repository so volunteer 
community members could fork it in response to a “CIDOC-CRM.org Website 
Make-over Challenge” with friendly competition encouraged by general public as 
well as a category for student/class projects.There are a number of other 
active issues/ideas I would like to contribute to the current SIG conversations 
that will surely take place next week, but I don’t want to dilute my message 
about @FactMiners interest in contributing to the new website.RECOMMENDATION 
FOR PREFERRED SOCIAL MEDIA HASHTAG - #cidocCRMHowever, I will slip this 
recommendation into this self-introduction note to suggest that the SIG 
consider officially endorsing/recommending the use of #cidocCRM as the 
preferred hashtag for CIDOC CRM social media communication. My experience is 
that anything with any variation of tag that has a plain CRM or hyphenated 
#CIDOC-CRM etc., will attract the “900-pound gorilla” of Customer Relationship 
Management folks that subvert conversations or spike your followers with 
inappropriate bots or well-meaning lurkers. My choice of #cidocCRM is that the 
CIDOC aspect should not be the “shouty” part and that it serves as the 
“category discriminator” that will help keep our interests separate from “those 
other” CRM folks.POSSIBLE SIG MEMBERSHIP?Finally, given my intense interest in 
the #cidocCRM and not knowing how ICOM and/or CIDOC SIGs work, I am unsure 
whether I would be a prospective group member in that I am an unaffiliated, 
independent Citizen Scientist and on a limited fixed “retirement” budget.Thank 
you for your interest and reading this notably long initial letter of 
introduction.    Happy-Healthy Vib

Re: [Crm-sig] Participation to forthcoming meeting

[Dominic Oldman]

I am 19th and most of 20th
:-)
D



 On Friday, 8 May 2015, 16:34, Richard P Smiraglia  wrote:


 I cannot attend; it's final exams and commencement in the U.S.

Richard P. Smiraglia, Professor
Editor-in-Chief, Knowledge Organization
Knowledge Organization Research Group,
School of Information Studies
University of Wisconsin Milwaukee
smira...@uwm.edu


From: Crm-sig  on behalf of Chryssoula Bekiari 

Sent: Friday, May 8, 2015 5:48 AM
To: crm-sig
Cc: Stella Sylaiou
Subject: [Crm-sig] Participation to forthcoming meeting

Dear All
I would like to ask you about your participation to the forthcoming
meeting in Nuremberg.
The provisional agenda of the meeting has been published on the site
http://www.cidoc-crm.org/agentas/33rd-sig-agenda(provisional)-v2.pdf.

best regards

Chryssoula

--
--
Chryssoula Bekiari
Research and Development Engineer

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

N. Plastira 100, Vassilika Vouton, GR-700 13 Heraklion, Crete, Greece
Phone: +30 2810 391631, Fax: +30 2810 391638, Skype: xrysmp
E-mail: beki...@ics.forth.gr

Web-site: http://www.ics.forth.gr/isl/people/people_individual.jsp?Person_ID=13
-


___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] ISSUE 272

[Dominic Oldman]

On first reading this seems both precise but also very useful generally. I will 
read again over the weekend.

D


Dominic Oldman
ResearchSpace Principal Investigator,
British Museum
Sent from Blackberry: 07980865309

From: martin [mailto:mar...@ics.forth.gr]
Sent: Friday, March 20, 2015 06:46 PM
To: crm-sig 
Subject: [Crm-sig] ISSUE 272

Dear All,

Here the scope note for E18:

E18 Physical Thing
Subclass of: E72 Legal Object
Superclass of: E19 Physical Object
E24 Physical Man-Made Thing
E26 Physical Feature


Scope Note: This class comprises all persistent physical items with a 
relatively stable form, man-made or natural.



Depending on the existence of natural boundaries of such things, the CRM 
distinguishes the instances of E19 Physical Object from instances of E26 
Physical Feature, such as holes, rivers, pieces of land etc. Most instances of 
E19 Physical Object can be moved (if not too heavy), whereas features are 
integral to the surrounding matter.



The CRM is generally not concerned with amounts of matter in fluid or gaseous 
states.

Examples:
§   the Cullinan Diamond (E19)
§   the cave “Ideon Andron” in Crete (E26)
§   the Mona Lisa (E22)
Properties:
P44 has condition (is condition of): E3 Condition State
P45 consists of (is incorporated in): E57 Material
P46 is composed of (forms part of): E18 Physical Thing
P49 has former or current keeper (is former or current keeper of): E39 Actor
P50 has current keeper (is current keeper of): E39 Actor
P51 has former or current owner (is former or current owner of): E39 Actor
P52 has current owner (is current owner of): E39 Actor
P53 has former or current location (is former or current location of): E53 Place
P58 has section definition (defines section): E46 Section Definition
P59 has section (is located on or within): E53 Place
P128 carries (is carried by): E90 Symbolic Object
P156 occupies: E53 Place
P159 occupied: E92 Spacetime Volume


E18 Physical Thing
Subclass of: E72 Legal Object
Superclass of: E19 Physical Object
E24 Physical Man-Made Thing
E26 Physical Feature


Scope Note: This class comprises all persistent physical items with a 
relatively stable form, man-made or natural.



Depending on the existence of natural boundaries of such things, the CRM 
distinguishes the instances of E19 Physical Object from instances of E26 
Physical Feature, such as holes, rivers, pieces of land etc. Most instances of 
E19 Physical Object can be moved (if not too heavy), whereas features are 
integral to the surrounding matter.


An instances of E18 Physical Thing occupies not only a particular geometric 
space, but in the course of its existence it performs a trajectory through 
spacetime, which occupies a real, that is phenomenal, volume in spacetime. We 
include in the occupied space the space filled by the matter of the physical 
thing and all its inner spaces, such as the inner of a box. Physical things 
consisting of aggregations of physically unconnected objects, such as a set of 
chessmen, occupy a number of individually contiguous spacetime volumes equal to 
the number of unconnected objects that constitute them.



Even though the substance of an instance of E18 Physical Thing is matter and 
hence different from the substance of a spacetime volume, which is an 
aggregation of 4 dimensional points in spacetime, the real spatiotemporal 
extent of an instance of E18 Physical Thing is regarded to be unique to it due 
to all its details and fuzziness. Its identity and existence depends uniquely 
on the identity of the instance of E18 Physical Thing. Therefore we model E18 
Physical Thing to be a subclass of E72 Legal Object and of E92 Spacetime 
volume, a “phenomenal” one (see Hiebel et al.). By virtue of this multiple 
inheritance, we avoid representing each instance of E18 Physical Thing together 
with an instance of its associated spacetime volume, if we want to talk about 
the places it occupies through time. This model, even though combining two 
distinct kinds of substance, is unambiguous, effective and corresponds to the 
intuitions of natural language.



The CRM is generally not concerned with amounts of matter in fluid or gaseous 
states.

Examples:
§   the Cullinan Diamond (E19)
§   the cave “Ideon Andron” in Crete (E26)
§   the Mona Lisa (E22)
Properties:
P44 has condition (is condition of): E3 Condition State
P45 consists of (is incorporated in): E57 Material
P46 is composed of (forms part of): E18 Physical Thing
P49 has former or current keeper (is former or current keeper of): E39 Actor
P50 has current keeper (is current keeper of): E39 Actor
P51 has former or current owner (is former or current owner of): E39 Actor
P52 has current owner (is current owner of): E39 Actor
P53 has former or current location (is former or current location of): E53 Place
P58 has section definition (defines section): E46 Section Definition
P59 has section (is located on or within): E53 Place
P128 carries (is carried by

[Crm-sig] Twitter @CRMSIG

[Dominic Oldman]

The CRMSIG Twitter page currently has 70 followers which have resulted from 
following 652 museums and museum related personnel. I add new ones every week.


Many of the followers are currently UK local and regional museums reflecting my 
bias but I have started getting followers in mainland europe and Asia. 


I will continue to add new organisations and people so that CRMSIG 
announcements can be communicated to a wide range of people. 

Please suggest relevant cultural heritage organisations or people that have 
twitter addresses and I will add them.

Cheers,

Dominic

Re: [Crm-sig] Money, money, money...

[Dominic Oldman]

I have sent the BM models and interface.

It is stuck in the list because of the size of attachement.

D



 From: martin 
To: crm-sig@ics.forth.gr 
Sent: Friday, February 6, 2015 12:00 PM
Subject: Re: [Crm-sig] Money, money, money...
 

Dear All,

I think the issue of business transactions with monetary exchange and other
exchange goods is overdue.
In order to address this in CRM-SIG, we need a some database schema/ 
data structure
in scope we can take as empirical material.
I believe acquisition of museum objects is one area of application. 
Another, I was
just recently pointed to, is transcription of Bronce Age texts.

Please propose as many data structures as possible to study requirements.

Best,

Martin

On 6/2/2015 2:12 πμ, Stephen Stead wrote:
> Dan
> I stick by my original points.
> It is not P16 used specific object unless you want to refer to a particular
> coin or note ie this is the coin that was used to buy the pen that was used
> to sign the treaty.
> Rgds
> SdS
>
> Stephen Stead
> Tel +44 20 8668 3075
> Mob +44 7802 755 013
> E-mail ste...@paveprime.com
> LinkedIn Profile http://uk.linkedin.com/in/steads
>
>
> -Original Message-
> From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr] On Behalf Of Dan Matei
> Sent: 05 February 2015 20:48
> To: crm-sig@ics.forth.gr; vladimir.alex...@ontotext.com
> Subject: [Crm-sig] Money, money, money...
>
> Dear all
>
> I have to state a "simple" fact: "The object X is purchased with Y euro."
>
> I found the 2011 discussion between Vladimir Alexiev and Stephen Stead on
> this topic:
> http://lists.ics.forth.gr/pipermail/crm-sig/2011-November/001693.html
>
> I'm not quite happy with their conclusion :-(
>
> Two issues:
>
> A.    The relationship between the purchasing event and the money paid
>
> I think that the natural relationship between the crm:E8_Acquisition and the
> amount paid (Y) is crm:P16_used_specific_object.
>
> [P16 SN: This property describes the use of material or immaterial things in
> a way essential to the performance or the outcome of an E7 Activity.]
>
> The money is "essential to the performance" of the acquisition, no ? :-)
>
>
> B.    Which is the right class of the "money" ?
>
> B.1. The amount is a crm: E72_Legal_Object, right ?
>
> [E72 SN: This class comprises those material or immaterial items to which
> instances of E30 Right, such as the right of ownership or use, can be
> applied.]
>
> Rights apply to money, right ?
>
> So, my (first) solution is:
>
> [
>      {
>          "@id": "#X",
>          "@type": "crm:E22_Man-Made_Object",
>          "statement": {
>              "@id": "#s1",
>              "predicate": "crm:P24i_changed_ownership_through",
>              "object": "#purchase"
>          }
>      },
>      {
>          "@id": "#purchase",
>          "@type": "crm:E8_Acquisition",
>          "statement": {
>              "@id": "#s2",
>              "predicate": "crm:P16_used_specific_object",
>              "predicateQualifier": "#amountPaid",
>              "object": "#price"
>          }
>      },
>      {
>          "@id": "#price",
>          "@type": "crm:E72_Legal_Object",
>          "statement": [
>              {
>                  "@id": "#s3",
>                  "predicate": "crm:P2_has_type",
>                  "object": "#currency"
>              },
>              {
>                  "@id": "#s4",
>                  "predicate": "crm:P43_has_dimension",
>                  "object": "#amount"
>              }
>          ]
>      },
>      {
>          "@id": "#amount",
>          "@type": "crm:E54_Dimension",
>          "statement": [
>              {
>                  "@id": "#s5",
>                  "predicate": "crm:P2_has_type",
>                  "object": "#sum"
>              },
>              {
>                  "@id": "#s6",
>                  "predicate": "crm:P90_has_value",
>                  "object": {
>                      "@value": "Y",
>                      "@type": "xsd:integer"
>                  }
>              },
>              {
>                  "@id": "#s7",
>                  "predicate": "crm:P91_has_unit",
>                  "object": "#euro"
>              }
>          ]
>      }
> ]
>
> A bit long... And the entity #price do not tells much.
>
>
> B.2. An amount of money is not an instance of crm: E54_Dimension ?
>
> [E54 SN: An instance of E54 Dimension represents the true quantity,
> independent from its numerical approximation, e.g. in inches or in cm.]
>
> A sum of money is not "a true quantity" ? I'm inclined to the affirmative.
> So, if I understand correctly the E54, I could use a double instantiation
> and shorten a bit my solution:
>
> [
>      {
>          "@id": "#X",
>          "@type": "crm:E22_Man-Made_Object",
>          "statement": {
>              "@id": "#s1",
>              "predicate": "crm:P24i_changed_ownership_through",
>              "object": "#purchase"
>          }
>      },
>      {
>          "@id": "#

[Crm-sig] EventBrite - Monday morning session

[Dominic Oldman]

Further to Donna's email I will be advertising the introduction to CRM sessions 
more widely today.

Cheers,

Dominic

[Crm-sig] CRM Primer

[Dominic Oldman]

The responses on the Linkedin CIDOC community on the Primer have been positive. 

This comment was posted recently

"Thank you very much, this is a very useful document! What I am trying to 
describe are not physical objects at all, but E28 Conceptual Objects: 
Performance Art. Not very easy, but CIDOC CRM seems to serve well."

Anni Saisto
Special researcher at City of Pori

Its good to get these responses from people new to the CIDOC CRM (which was the 
aim of the Primer) and I will take all the responses that I have had to make 
improvements for future versions.

Cheers,

Dominic

Re: [Crm-sig] Coins 2 CRM (again)

[Dominic Oldman]

Didn't Augustus issue coins with political messages specifically for 
communication or "propaganda" purposes. (e.g.Augustus and the Republic). The 
intention might have been more orientated to the message?

I expect this message purpose was/is quite common on coins and notes.

Incidentally, my daughter has a collection of Olympic 50p coins. They are 
standard currently coins rather than simply commemorative but have different 
sport scenes. Although I think she might have spent them now. :-)

D






 From: Stephen Stead 
To: 'Christian-Emil Smith Ore'  
Cc: crm-sig@ics.forth.gr 
Sent: Thursday, November 20, 2014 6:54 PM
Subject: Re: [Crm-sig] Coins 2 CRM (again)
 

I am not entirely convinced that this statement is true. The intension of the 
coins creator is probably not to carry the immaterial object about, but to 
perform the function of enabling trade. The immaterial object is a mechanism 
for conveying authenticity. I agree that some coins carry immaterial objects 
and that these can presumably be part of a Work and Expression family. 
A commemorative medal would be a contender for being an information carrier as 
it is designed to carry the commemorative inscription but not so sure about 
coins and I would definitely say that tokens (with no design) would fall 
outside the scope of information carrier.
If we want to say that coins are E84 Information Carriers then we may need to 
revise the scope note.

Stephen Stead
Tel +44 20 8668 3075 
Mob +44 7802 755 013
E-mail ste...@paveprime.com
LinkedIn Profile http://uk.linkedin.com/in/steads

-Original Message-
From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr] On Behalf Of Christian-Emil 
Smith Ore
Sent: 20 November 2014 17:02
To: Maria Theodoridou; crm-sig@ics.forth.gr
Subject: Re: [Crm-sig] Coins 2 CRM (again)

My view is that a coin is an information carrier and indeed is of the category 
of objects found and stored  in a library C-E

>-Original Message-
>From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr] On Behalf Of Maria 
>Theodoridou
>Sent: Thursday, November 20, 2014 4:34 PM
>To: crm-sig@ics.forth.gr
>Subject: Re: [Crm-sig] Coins 2 CRM (again)
>
>Dear Dan,
>
>Indeed we have considered your thoughts and  we have defined as 
>extensions for the coins and later for the CRM:
>
>
>    E12 Production. PC1 produced things of type: E55 Type
>    E22 Man-Made Object. PC2 is example of: E55 Type
>
>
>Both PC1 and PC2 are subproperties of P2 has type
>
>The above are depicted in slide 23 in my presentation where I describe 
>how we modeled the categorical production.
>
>We believe that PC1 and PC2 are a generalization of R26 produced things 
>of type and R7 is example of of FRBR.
>FRBR is not suitable for our coin modeling since it refers to 
>bibliographic information, as Christian-Emil pointed out.
>
>It is open for discussion  if there is a need for generalizing F32 
>Manifestation Product Type
>
>This is a topic for future discussion in CRM-SIG.
>
>Best regards,
>Maria
>
>
>On 19/11/2014 3:02 μμ, Dan Matei wrote:
>
>
>    Dear Maria
>
>
>
>    Thanks you. I've read your (very useful) London presentation:
>
>
>
>    http://www.slideshare.net/MariaTheodoridou/london-meetup2014-
>mappingchi2cidoccrm
>mappingchi2cidoccrm>
>
>
>
>    and I plan to take advantage of the mapping:
>http://www.ics.forth.gr/isl/3M 
>
>
>
>    But I'm tempted to treat the coins as exemplars of an "issue", i.e.
>
>
>
>     
>
>
>
>
>    IMHO, a thing like:
>
>
>
>    http://numismatics.org/ocre/id/ric.1(2).cl.31
>
>
>
>
>    is a F3, mutatis mutandis.
>
>
>
>    When you did your mapping did you considered something like this ?
>And which were the arguments against ?
>
>
>
>    Best,
>
>
>
>    Dan
>
>
>
>
>
>    ___
>    Crm-sig mailing list
>    Crm-sig@ics.forth.gr
>    http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>
>
>--
>---
>-
>Maria Theodoridou
>R & D Engineer
>
>Information Systems Laboratory & Centre for Cultural Informatics 
>Institute of Computer Science Foundation of Research and Technology - 
>Hellas (FORTH) Science and Technology Park of Crete Vassilika Vouton, 
>P.O.Box 1385, GR-711
>10 Heraklion, Crete, Greece
>
>Tel.: +30-2810-391731  Fax:  +30-2810-391638  E-mail: 
>ma...@ics.forth.gr
>URL: 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

[Crm-sig] Europeana election

[Dominic Oldman]

Hi CRM-SIG,

I am trying to get CRM-SIG representation on the Europeana council and have put 
myself forward as a councilor. 

You can vote for me here (if you wish). 
https://www.surveymonkey.com/s/EuropeanaElection2014

Cheers,

Dominic

Re: [Crm-sig] ISSUE: Re: Çatalhöyük excavation data

[Dominic Oldman]

Hi Martin,

1. This is obviously not what the list is for and not something that I would 
normally respond to.

2. My organisation is mentioned as part of the email which additionally puts me 
(potentially) in an uncomfortable position.

In this case it is partly because we are currently testing other systems 
at the moment and are likely to be moving to an open source system in 
the near future. I am happy to discuss our reasons or experience with 
anyone (and these reasons should not be assumed) but these are not things that 
are appropriate to discuss on this list. 


The criteria for being part of the list should be about furthering the 
objectives of the CRM-SIG and supporting the CIDOC CRM community - and it is 
right to protect it from becoming commercialised whether directly or 
indirectly. 
Dominic


   

  





 From: martin 
To: crm-sig@ics.forth.gr 
Sent: Thursday, October 16, 2014 12:19 PM
Subject: [Crm-sig] ISSUE: Re:  Çatalhöyük excavation data
 

Dear All,

I have preliminarily unsubscribed Vladimir from this list, because I regard this
as commercial advertisement.

Please comment.

Best,

Martin


On 16/10/2014 12:47 μμ, Vladimir Alexiev wrote:
>> I recently published a lot of Çatalhöyük excavation data
>> The endpoint is
>> http://regis.stanford.edu/openrdf-sesame/Catal2013
>> and some explanation and sample queries are here:
>> http://catalhoyuk.stanford.edu/index.php#/3/0///
> Hi Karl!
> That's quite nice, esp. the explanation page and the sample queries.
> 
> What repository do you use? I noticed some of the queries are slow...
> If you want to try your hand at OWLIM (now called GraphDB), drop me a note.
> It's used by some of the largest CH repositories (some of which were 
> discussed here under the topic "SPARQL endpoints"):
> Europeana, Polish DL, British Museum, Getty vocabularies, YCBA, CHARISMA 
> (conservation portal), 3D COFORM...
> 
> Your page says "Spatial queries on the graph await implementation of 
> GeoSPARQL".
> While OWLIM does not yet have full GeoSPARQL, it has checking by radius and 
> bounding box,
> see http://vocab.getty.edu/doc/#Places_Within_Bounding_Box and the following 
> few queries.
> E.g. one is "find Castles near Mountains"
> 
> Cheers!
> --
> Vladimir Alexiev, PhD, PMP
> Lead, Data and Ontology Management Group
> Ontotext Corp, www.ontotext.com
> Sirma Group Holding, www.sirma.com
> Email: vladimir.alex...@ontotext.com, skype:valexiev1
> Mobile: +359 888 568 132, SMS: 359888568...@sms.mtel.net
> Landline: +359 (988) 106 084, Fax: +359 (2) 975 3226
> Calendar: https://www.google.com/calendar/embed?src=vladimir%40sirma.bg
> 
> 
> 
> 
> 
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig


-- 
--
Dr. Martin Doerr              |  Vox:+30(2810)391625        |
Research Director             |  Fax:+30(2810)391638        |
                               |  Email: mar...@ics.forth.gr |
                                                             |
               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               |
                                                             |
             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] Crm-sig Digest, Vol 93, Issue 3

[Dominic Oldman]

Done!

Welcome to the list.

D 




 From: Karl Grossner 
To: crm-sig@ics.forth.gr 
Sent: Thursday, October 9, 2014 3:57 PM
Subject: Re: [Crm-sig] Crm-sig Digest, Vol 93, Issue 3
 

Stephen, Dominic -

I wonder what counts as a CRM endpoint. I recently published a lot of 
Çatalhöyük excavation data, which includes a handful of ecrm: properties and 
classes, mostly describing top-level spatial relations on the site. There is a 
plan afoot to implement crmeh: eventually.

The endpoint is 
http://regis.stanford.edu/openrdf-sesame/Catal2013 

and some explanation and sample queries are here: 
http://catalhoyuk.stanford.edu/index.php#/3/0///


Karl

-- 
Karl Grossner, PhD 
Digital Humanities Research Developer 
Stanford University Libraries 
Stanford,CA US 
www.kgeographer.org 


- Original Message -
> Send Crm-sig mailing list submissions to
>     crm-sig@ics.forth.gr
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>     http://lists.ics.forth.gr/mailman/listinfo/crm-sig
> or, via email, send a message with subject or body 'help' to
>     crm-sig-requ...@ics.forth.gr
> 
> You can reach the person managing the list at
>     crm-sig-ow...@ics.forth.gr
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Crm-sig digest..."
> 
> Today's Topics:
> 
>    1. Re: [Culturebrokers] SPARQL endpoints (Dominic Oldman)
> 
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
> 


___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] [Culturebrokers] SPARQL endpoints

[Dominic Oldman]

This doesn't look like a CRM endpoint at first glance?

D



 From: Paul Cripps 
To: "crm-sig@ics.forth.gr"  
Sent: Thursday, October 9, 2014 1:30 AM
Subject: Re: [Crm-sig] [Culturebrokers] SPARQL endpoints
 


ADS:
http://data.archaeologydataservice.ac.uk/page/ Dominic Oldman 
 wrote: 

Claros

http://data.clarosnet.org/sparql/


There ain't very many out there yet.

D




 From: Stephen Stead 
To: crm-sig@ics.forth.gr; culturebrok...@listserv.ylm.se; 'FRBR Group' 
 
Sent: Thursday, October 9, 2014 12:13 AM
Subject: [Culturebrokers] SPARQL endpoints



 
Does anybody have a list of CRM SPARQL endpoints.
Currently I know of:-
British Museum
Yale Centre for British Art (YCBA)
Any others?
Perhaps we should start  a register on the SIG web presence. What do people 
think?
Rgds
SdS
 
Stephen Stead
Director
Paveprime Ltd
35 Downs Court Rd
Purley, Surrey 
UK, CR8 1BF
Tel +44 20 8668 3075 
Fax +44 20 8763 1739
Mob +44 7802 755 013
E-mail ste...@paveprime.com
LinkedIn Profile http://uk.linkedin.com/in/steads
 



___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] [Culturebrokers] SPARQL endpoints

[Dominic Oldman]

Claros

http://data.clarosnet.org/sparql/


There ain't very many out there yet.

D




 From: Stephen Stead 
To: crm-sig@ics.forth.gr; culturebrok...@listserv.ylm.se; 'FRBR Group' 
 
Sent: Thursday, October 9, 2014 12:13 AM
Subject: [Culturebrokers] SPARQL endpoints
 


Does anybody have a list of CRM SPARQL endpoints.
Currently I know of:-
British Museum
Yale Centre for British Art (YCBA)
Any others?
Perhaps we should start  a register on the SIG web presence. What do people 
think?
Rgds
SdS
 
Stephen Stead
Director
Paveprime Ltd
35 Downs Court Rd
Purley, Surrey 
UK, CR8 1BF
Tel +44 20 8668 3075 
Fax +44 20 8763 1739
Mob +44 7802 755 013
E-mail ste...@paveprime.com
LinkedIn Profile http://uk.linkedin.com/in/steads

Re: [Crm-sig] More subclasses for E33_Linguistic_Object ?

[Dominic Oldman]

Good discussion bringing out an important point about multiple instantiation.

Cheers,

D




Dominic Oldman
ResearchSpace Principal Investigator,
British Museum
Sent from Blackberry: 07980865309

From: Dan Matei [mailto:danmate...@gmail.com]
Sent: Tuesday, September 16, 2014 06:28 AM
To: martin 
Cc: crm-sig@ics.forth.gr 
Subject: Re: [Crm-sig] More subclasses for E33_Linguistic_Object ?

OK. I withdrow the term "acrobatic" :-)

Thanks friends,

Dan

On 15 September 2014 23:18, martin 
mailto:mar...@ics.forth.gr>> wrote:
Hi Dan,

On 15/9/2014 8:37 πμ, Dan Matei wrote:
Hi Martin

On 14 September 2014 21:40, martin 
mailto:mar...@ics.forth.gr>> wrote:

We use to solve this with multiple instantiation (E49, E33).  Note that most 
place names
or not language specific. Few bigger places use to have language variants.
See also FRBRoo 2.0, about name use practice.

Yes, but why using acrobatic solutions ? There is a strong reason against 
making those classes subclasses of E33_Linguistic_Object ?
Well, we regard that many (most) Appellations do not have a language. If we 
accept that, making linguistic object a superclass of appellation just because 
sometimes the property may appear, violates all principles of generalization.
Even if you have thousands of bilingual placenames, there are a million more 
which do not have a language equivalent,
and many which have survived different cultures.

Multiple instantiation is not "acrobatic",
but a very important feature of KR models like RDF, giving credit to the fact 
that there are incidental combinations
of classes on particular instances. For instance, I can make a spoon-knife, its 
a real spoon, a real knife, but nothing more
to say about it as a category. Avoiding to subclass any combination of classes 
that may appear in some reality, is one of the fundamental principles that has 
kept the CRM as small as it is. In terms of implementation, the overhead is 
negligible, and not "acrobatic ;-) ".

If we want to be more precise, it is not the name which is translated, but the 
place which is renamed. A place "St. John" in Canada is not called "Sankt 
Johann" by Austrians, nor vice versa. The cases in which the placename in two 
languages is unique is even more rare.

Best,

Martin

Cheers,

Dan

PS. True that Paris has few language variants. But in my Transylvania there are 
thousends bilingual (Romanian and Hungarian) place names. Not to mention the 
German ones :-)



--

--
 Dr. Martin Doerr  |  Vox:+30(2810)391625|
 Research Director |  Fax:+30(2810)391638|
   |  Email: 
mar...@ics.forth.gr<mailto:mar...@ics.forth.gr> |
 |
   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   |
 |
 Web-site: http://www.ics.forth.gr/isl   |
--





--
---
Dan Matei
Institutul Național al Patrimoniului (National Heritage Institute) - București
Fundația Gellu Naum
TermRom - Asociația Română de Terminologie

Re: [Crm-sig] Fwd: IFLA FRBR RG endorsement of PRESSoo

[Dominic Oldman]

Dear Pat,

Thanks for this. OK, I will wait for the IFLA posting.

Cheers & congratulations,

Dominic









 From: Riva Patricia 
To: Dominic Oldman ; martin ; crm-sig 
; FRBR Group  
Sent: Wednesday, August 20, 2014 4:39 PM
Subject: RE : [Crm-sig] Fwd: IFLA FRBR RG endorsement of PRESSoo
 


 
Hi Dominic,
 
I don't have a link at this time, we are all still at the IFLA conference until 
Friday. I just sent the info immediately to Christian-Emil so that he would 
know in time so that the CIDOC board could take the equivalent step at the 
September conference. Eventually there will be a meeting report posted which 
will include this information, but not immediately. Also, the subsequent IFLA 
procedures involve posting and requesting comments-- that would be a good time 
to forward the information far and wide. 
 
Regards, Pat
 
Pat Riva
Bibliothécaire responsable de la normalisation bibliographique
Direction du traitement documentaire des collections patrimoniales
Bibliothèque et Archives nationales du Québec

2275, rue Holt
Montréal (Québec) H2G 3H1
Téléphone : +1 514 873-1101 poste 3624
Télécopieur : +1 514 873-7296
pat.r...@banq.qc.ca
www.banq.qc.ca


 
De : Crm-sig [crm-sig-boun...@ics.forth.gr] de la part de Dominic Oldman 
[do...@oldman.me.uk]
Envoyé : 20 août 2014 06:52
À : martin; crm-sig; FRBR Group
Objet : Re: [Crm-sig] Fwd: IFLA FRBR RG endorsement of PRESSoo


Hi Martin,

This sounds great. My congratulations to all those involved. 

Can this be disseminated? Is there a link that I can refer to and use on the 
ResearchSpace site and on RS Twitter to communicate these achievements?

Cheers,

Dominic



 From: martin 
To: crm-sig ; FRBR Group  
Sent: Tuesday, August 19, 2014 5:21 PM
Subject: [Crm-sig] Fwd: IFLA FRBR RG endorsement of PRESSoo


Dear All,

We are happy to announce the endorsement of a new CRM-compatible model by the
IFLA FRBR Review Group. We will propose the corresponding endorsement by CIDOC.

Best,

martin


 Original Message 
Subject:    IFLA FRBR RG endorsement of PRESSoo
Date:    Sun, 17 Aug 2014 14:38:33 +
From:    Riva Patricia 


At its meeting today August 17, 2014, the FRBR Review Group formally endorsed 
PRESSoo. Quoting from the longer statement (attached):
"The FRBR Review Group endorses PRESSo as a valid ontology that can be used to 
express the semantic relationships embedded in descriptions provided by 
libraries (i.e., bibliographic authority data) for continuing resources in a 
way that is fully compatible
 with FRBRoo."

IFLA has additional formal steps, new this summer, related to getting final 
endorsement as an "IFLA Standard", but the FRBR RG endorsement is the first 
step, and essentially is the step that endorses the domain content of the 
PRESSoo model.

The FRBR RG also accepted a similar statement of endorsement for FRBRoo version 
2.0, and we will also be complying with the new steps for final approval of the 
updated version (FRBRoo version 1.o was considered approved under previous 
procedures).


Pat

Pat Riva
Bibliothécaire responsable de la normalisation bibliographique
Direction du traitement documentaire des collections patrimoniales
Bibliothèque et Archives nationales du Québec

2275, rue Holt
Montréal (Québec) H2G 3H1
Téléphone : +1 514 873-1101 poste 3624
Télécopieur : +1 514 873-7296
pat.r...@banq.qc.ca
www.banq.qc.ca


-- 
--
Dr. Martin Doerr              |  Vox:+30(2810)391625        |
Research Director            |  Fax:+30(2810)391638        |
                              |  Email: mar...@ics.forth.gr |
                                                            |
              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              |
                                                            |
            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] Fwd: IFLA FRBR RG endorsement of PRESSoo

[Dominic Oldman]

Hi Martin,

This sounds great. My congratulations to all those involved. 

Can this be disseminated? Is there a link that I can refer to and use on the 
ResearchSpace site and on RS Twitter to communicate these achievements?

Cheers,

Dominic



 From: martin 
To: crm-sig ; FRBR Group  
Sent: Tuesday, August 19, 2014 5:21 PM
Subject: [Crm-sig] Fwd: IFLA FRBR RG endorsement of PRESSoo
 

Dear All,

We are happy to announce the endorsement of a new CRM-compatible model by the
IFLA FRBR Review Group. We will propose the corresponding endorsement by CIDOC.

Best,

martin


 Original Message 
Subject:     IFLA FRBR RG endorsement of PRESSoo
Date:     Sun, 17 Aug 2014 14:38:33 +
From:     Riva Patricia 


At its meeting today August 17, 2014, the FRBR Review Group formally endorsed 
PRESSoo. Quoting from the longer statement (attached):
"The FRBR Review Group endorses PRESSo as a valid ontology that can be used to 
express the semantic relationships embedded in descriptions provided by 
libraries (i.e., bibliographic authority data) for continuing resources in a 
way that is fully compatible with FRBRoo."

IFLA has additional formal steps, new this summer, related to getting final 
endorsement as an "IFLA Standard", but the FRBR RG endorsement is the first 
step, and essentially is the step that endorses the domain content of the 
PRESSoo model.

The FRBR RG also accepted a similar statement of endorsement for FRBRoo version 
2.0, and we will also be complying with the new steps for final approval of the 
updated version (FRBRoo version 1.o was considered approved under previous 
procedures).


Pat

Pat Riva
Bibliothécaire responsable de la normalisation bibliographique
Direction du traitement documentaire des collections patrimoniales
Bibliothèque et Archives nationales du Québec

2275, rue Holt
Montréal (Québec) H2G 3H1
Téléphone : +1 514 873-1101 poste 3624
Télécopieur : +1 514 873-7296
pat.r...@banq.qc.ca
www.banq.qc.ca


-- 
--
Dr. Martin Doerr              |  Vox:+30(2810)391625        |
Research Director             |  Fax:+30(2810)391638        |
                               |  Email: mar...@ics.forth.gr |
                                                             |
               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               |
                                                             |
             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] Document for approval

[Dominic Oldman]

Dear Mark,

On E42_Identifier

Yes, you are correct.  This is simply a typing mistake easily rectified and I 
am very grateful for you picking up on this.

On 9.3 – I am happy to change this to “Examples” as you suggest.

Indeed, these are constructive comments.

Thanks,

Dominic



From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr] On Behalf Of Mark Fichtner
Sent: 12 August 2014 17:04
To: crm-sig@ics.forth.gr
Subject: Re: [Crm-sig] Document for approval

Dear all,

it seems that you feel yourself personally offended, Barry. I don't think Georg 
did mean this, Martin asked for feedback and he got some - personally I think 
that is the best that can happen for science.

I think many points which Georg mentioned are valid. I don't want to repeat 
them, I just also got the same impression that Georg got from the document. I 
want to explain my point of view with PDF pages 13-14 (labeled 11-12 in the 
document itself - I would suggest to make this consistent, too.):
This paragraph is labelled "9.2 Example of using Entities with Properties with 
RDF" - so it is an example and examples should be easy to understand because 
they illustrate important parts. However the image on top of page 14 (or 12 due 
to the label on the page) is absolutely not the semantically equivalent in rdf 
to the image on the bottom of page 11 which illustrates the CRM view. A 
possible correction is illustrated in the attachment.

If you look carefully at the current image, then you can see that it is 
semantically equivalent to: "http://collection.amuseum.org/id/object/1234 being 
a E42_Identifier and a E22_Man-made_Object at the same time and refering to 
itself via P1_is_identified_by." However the crm-example states "There is a Man 
Made Object which is called The Hoa Hakananai and it is identified by an 
identifier which is an accession number". This is not what the primer tries to 
describe above, it is not easy to understand, not logical correct, not the rdf 
representation of the crm view above and therefore just a bad example in a 
primer. Thank you for pointing that out, Georg, I didn't see it so clear this 
way before.


The following part is labelled "9.3 URI Schema" and not "9.3 Examples for a 
consistent URI Schema". Furthermore it states that "Resources (like an object 
or an identifier) are assigned a URI providing a logical structure when
implementing RDF. URI schemata are created to reflect the resources in 
question.". This means that the URI has to provide "a logical structure" - what 
are the requirements for this "logical structure" in detail? Is a UUID a valid 
logical structure? Why are all examples URLs?

Perhaps this helps to get this a little bit more constructive.

Best regards,

Mark Fichtner

2014-08-12 17:04 GMT+02:00 Barry Norton 
mailto:bnor...@britishmuseum.org>>:




-Original Message-
From: Crm-sig 
[mailto:crm-sig-boun...@ics.forth.gr] On 
Behalf Of Georg Hohmann
Sent: 12 August 2014 15:33
To: crm-sig@ics.forth.gr
Subject: Re: [Crm-sig] Document for approval



>> Georg, your comment about the URI scheme into which a given material

>> fits seems motivated not by the Primer but rather by the British

>> Museum data

>

> Since the the URI scheme of the BM is given as a linked data example in the 
> primer, my comments are about the texts

> and the figures in the primer and the purpose they serve.



The mention of /material in the example URIs is just an arbitrary example of 
object-specific resources and I've agreed with Dominic that this can be changed 
or dropped if it confuses.



Again, the Primer does not cover that there are two sources of resources for 
materials in the BM data; the confusion only arises when you look at a larger 
example than the Primer and don't examine resources in terms of their 
relationships but instead focus on the URIs.





>> That being said, one should not attempt to 'read' URIs, that's a basic

>> principle of REST as much as Linked Data;

>

> Yes, for sure. So why should a primer include an example that creates the 
> appearance that URIs

> should have a structure that makes them "more readable" for humans?



If that's the impression then it should be clarified. As it standard for REST 
over HTTP the URIs should be crafted to be maintainable for the service 
provider (which is the intention of this exemplar scheme), not transparent to 
the user.





> it will be hard to find any other resource that mints URIs the way that is 
> given in the primer, because -

> as you said yourself - it is not common practice.



Well, I don’t think I’ve said that, but equally it’s not intended to be(come) 
common practice. The URI scheme of the Primer illustrates that one can 
establish a consistent hierarchical URI scheme to publish data according to the 
CRM, not that one must follow the particular scheme used in examples (which 
seems to offend you because it’s a projection from the BM one, but it

Re: [Crm-sig] Document for approval

[Dominic Oldman]

Apologies,

None of my emails have made it to the list - probably for a long time - but I 
haven't been getting a bounce.

Below is the last email which explains the rationale for the paper.

I would add this. We wanted the paper to be as short as possible. The 
additional information on RDF/Linked data is more about orientation. They 
answer questions that are not deep and technical but provide some insight at a 
high level about how some aspects work in practice. The document is not aimed 
at people who want to start programming. There is little point having detailed 
technical discussions about the details of RDF and URI with respect to this 
paper. This misses the point.

We all come from different backgrounds but all already have an understanding of 
a lot of the issues. The real test is when non CRM-SIG people read it and 
feedback. Therefore although I have posted this paper to the list I have also 
given review copies to people who have no dealing and knowledge of CRM i.e. the 
people that this document is aimed at. We can debate this till the cows come 
home but the real test is whether we can convey what the CRM is about to people 
who don't know anything about it but work in an environment where it is 
relevant for them to know about it.

The first two responses were as follows;

A project manager working on general business projects. The questions were;

1. Did you understand the CRM after reading the document. Ans: Yes
2. Was it at the right level for you. Ans: Yes
3. Do you think it would be useful for other people in other posts: Ans: Yes  
(e.g. People working with digital content, people working with museum systems 
(CMS), people who use the data (curators, researchers), Managers of all those 
roles. Other types of managers might not get it.  
4. Did you think it was over complicated: Ans: No
5. Did you think it was too simple: Ans: No
6. Things that could have been done better: Ans: More analogies could be useful.
7. Was the technical content the right level: depends - it was fine for me. 
Some people might want to know more technical information but memorable 
examples are more important.
8. General comments:

You can't just skim it or read bits (unless you know the CRM already) you need 
to read all the way through it to get the benefit from the document.


I haven't got the full response from a second reader yet (a Head Keeper of a 
Curatorial department) but the initial response was that they felt that they 
now understood the CRM to the level they needed but that the document could do 
with a few more examples.

My point being that it may be more useful to give the document to people who 
are not closely linked with CRM and linked data already and don't already have 
a firm view about what such a document should contain but the information may 
be relevant to them in the near future. The document is no use to people who 
already have a good understanding of these things. They do not need a Primer.

Thanks,

Dominic



 From: Georg Hohmann 
To: "crm-sig@ics.forth.gr"  
Sent: Tuesday, August 12, 2014 11:27 AM
Subject: Re: [Crm-sig] Document for approval
 

Dear Dominic,

> It would be nice if you also could tell me if you thought that there was
> anything positive and useful in the paper that you thought should stay?

It's hard to say as long as the primary focus of the paper is not
clear. To my understanding a primer is a document that provides a
brief overview of the goals, purposes, concepts, documents and sources
about a specific topic. This could be complemented by a rough
walkhtrough by example as Richard noted. There are several primers on
the web that could serve as a model.

There is already a "comprehensive introduction"
(http://cidoc-crm.org/comprehensive_intro.html) to the CRM available,
so first there should be a clear definition of audience to be
addressed by this paper. What is the kind of audience you had in mind?
I would prefer a primer that addresses people not only from the
cultural heritage sector who come in contact with the CRM the first
time. These people should be considered as museums staff(!),
historians, archaeologists, lingustists, librarians, archivists and so
on and not as computer scientists or linked data architects.

Given that, the first part of the paper (Chapter 1-7) could be a good
starting point for a primer with additional examples. Chapter 8-9 may
support the idea of "crm linked data guidlines", but I don't really
see the need for that. The purpose of Chapter 10 is unclear to me, the
part about "The Power of Big Data" doesn't fit (in this way) to the
idea of a primer.


Two additonal remarks:
- Overall it seems a bit odd that a document should be "approved as
CRM-SIG statement" that is obviously work in progress - at least
regarding the many comments, questions and underlinings in the
document itself. Why the hurry?
- As I'm not a frequent participant of the SIG meetings, it's a kind
of suprise to me that the SIG

Re: [Crm-sig] Document for approval

[Dominic Oldman]

Dear Georg (take two!),

That's a no then. ;-)   However, I can now see more clearly your issues, so 
thank you for this additional email.

The paper makes it very clear that CRM can be implemented using different 
models and is independent of technology.  I am happy to make this a stronger 
statement if you feel that it needs it. In Section 5 is states - "It is 
independent of any technical implementation framework". 

The use of RDF in this paper is simply as a device for showing examples. "Real" 
examples are important and users of the document have asked for them, and 
actually asked for more examples to be inserted. Whenever I make presentations 
to the Directors of the BM they ask for concrete examples. I am not sure why 
people are reluctant to provide them and why you wouldn't.

Commonly, because museums and other CH organisations are slowly entering the 
linked data world, people want to know what the connection is between CRM and 
linked data. It would be a mistake to try and show many different examples 
using different schemas in a Primer (I accept that you wouldn't provide any 
examples but I will come on to that later). This means that all the information 
that managers hear about linked data from all sorts of different sources can be 
associated with and have a connection with CRM information (from the Primer). 
This is an important point because if people don't understand that there is a 
connection then it might not be included/mentioned in organisational digital 
strategy policies that include a linked data strategy. It is therefore, without 
making any recommendations, extremely expedient to use linked data as the 
representational example and to make this valid association while still stating 
that it is neutral as to technology
 - which it is (we currently have BM CRM data in two different models one of 
which is not RDF). RDF just becomes a vehicle for showing how it works in 
practice. One aim of the primer should be to get people to use the CRM. What is 
the most likely way that they may use it? 

The common factor underlying some of your criticisms (for which I am very 
grateful that you have taken the time to provide) seem to imply a reluctance to 
give a non-technical audience some technical information. The idea of the 
Primer is not to teach people RDF or linked data but to show that CRM has real 
practical application and show that it is not just a theoretical and conceptual 
thing - something still assumed by some people. I am not sure why there is a 
problem with non-technical people seeing technical examples. This division is 
often cited as one of the reasons why the Digital Humanities is not progressing 
as it was envisaged. Digital Humanities needs Digital Humanists/Curators. For 
example, Unsworth 2002 statement. 


"Those representations — ontologies, schemas, knowledge representations, call 
them what you will — should be produced by people trained in the humanities. 
Producing them is a discipline that requires training in the humanities, but 
also in elements of mathematics, logic, engineering, and computer science"


Many technical people get very upset about showing supposedly “non-technical” 
people, technical examples. However, if we don't start introducing our curators 
(and humanists generally) to these things and continue to keep this knowledge 
separate, how can they participate in the discussions and the work more 
fully?The examples are very basic in any case, but why shouldn't curators (I am 
a curator) take an interest in some computer science and technology? Isn't that 
what Unsworth's quote is saying. This happens in other disciplines. 

There is no particular hurry or deadline. It would be good to have a Primer 
though and some people have got together in their own spare time to contribute 
some time towards producing one. That must be a good thing, and something that 
we can all be positive about. 

The CRM Lab was constituted at the CRM-SIG and has terms of reference which are 
on the site.  The link is here 
http://www.cidoc-crm.org/docs/29th-meeting-presentations/CRMLab%20Terms%20of%20Reference09.docx
 . The aims include;

1.Education of end users.
2.Implementation of CRM within new projects.
3.Specification and development of new tools to support the use of the CRM.
4.Specification of processes of good practice

The Primer was an agreed output from one of the SIG meetings. 

Thanks very much for your comments and I will certainly attend to some of the 
issues that you have kindly spotted.  

Cheers,


Dominic




 From: Georg Hohmann 
To: "crm-sig@ics.forth.gr"  
Sent: Tuesday, August 12, 2014 11:27 AM
Subject: Re: [Crm-sig] Document for approval
 

Dear Dominic,

> It would be nice if you also could tell me if you thought that there was
> anything positive and useful in the paper that you thought should stay?

It's hard to say as long as the primary focus of the paper is not
clear. To my understanding a primer is 

Re: [Crm-sig] *** ISSUE *** Revision of scope note for E73 Information Object to specifically include named graphs

[Dominic Oldman]

Hi Richard , All,

I am slightly confused about this discussion.

The purpose of the scope notes is to clarify the meaning of the entities and 
relationships that make up the CRM. The CRM models real world things both 
material and non-material.

Inclusion of a named graph example in the scope notes does not affect the 
technical independence of the standard. It simple says that this is an example 
(in this case) of a propositional object. We need to have examples that are 
practically useful and mean something to people.

In that context it personally bothers me not whether we have an example of a 
named graph or indeed other examples from other schema formats -  as long as it 
helps people to understand what a propositional object is (and its scope). We 
could equally use examples from other data schema worlds and again it would say 
nothing about the technical implementation of the CRM. None of these examples 
would affect the standard in terms of its neutrality. It's an illustrative 
scope note, but is not part of the standard in the context you describe.

Examples need to be wide and varied and cater for all the different types of 
people that use the CRM and want to understand how it works.

Cheers,

Dominic



From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr] On Behalf Of Richard Light
Sent: 28 July 2014 09:41
To: crm-sig@ics.forth.gr
Subject: Re: [Crm-sig] *** ISSUE *** Revision of scope note for E73 Information 
Object to specifically include named graphs

Martin,

I thought that a major merit of the CRM was that it was an abstract model, 
which could be instantiated using whatever technology was felt to be 
appropriate.  That being the case, I would be concerned if RDF-specific 
techniques were presented to the world as the only way in which a particular 
challenge ("implementing argumentation systems ...") could be tackled using the 
CRM.  Or are you talking specifically about RDF implementations of the CRM?

Why can't "premises and conclusions" be modelled using reification, so they can 
then be given a unique URI? This is the sort of approach which the BM has 
successfully deployed, as I understand it.  I would be grateful if someone 
could provide a really simple concrete example which shows the need for the 
named graph approach.

To pick up on the suggestion of using the AAT as an example: in what way is the 
AAT a named graph?  Surely it's a SKOS Concept Scheme (plus)?  I think it would 
be impossible to give an example of a "well-known" named graph, for the reasons 
Simon has been explaining.

Richard

Re: [Crm-sig] *** ISSUE *** Revision of scope note for E73 Information Object to specifically include named graphs

[Dominic Oldman]

Hi Richard , All,

I am slightly confused about this discussion.

The purpose of the scope notes is to clarify the meaning of the entities and 
relationships that make up the CRM. The CRM models real world things both 
material and non-material.

Inclusion of a named graph example in the scope notes does not affect the 
technical independence of the standard. It simple says that this is an example 
(in this case) of a propositional object. We need to have examples that are 
practically useful and mean something to people.

In that context it personally bothers me not whether we have an example of a 
named graph or indeed other examples from other schema formats -  as long as it 
helps people to understand what a propositional object is (and its scope). We 
could equally use examples from other data schema worlds and again it would say 
nothing about the technical implementation of the CRM. None of these examples 
would affect the standard in terms of its neutrality. It’s an illustrative 
scope note, but is not part of the standard in the context you describe.

Examples need to be wide and varied and cater for all the different types of 
people that use the CRM and want to understand how it works.

Cheers,

Dominic










From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr] On Behalf Of Richard Light
Sent: 28 July 2014 09:41
To: crm-sig@ics.forth.gr
Subject: Re: [Crm-sig] *** ISSUE *** Revision of scope note for E73 Information 
Object to specifically include named graphs

Martin,

I thought that a major merit of the CRM was that it was an abstract model, 
which could be instantiated using whatever technology was felt to be 
appropriate.  That being the case, I would be concerned if RDF-specific 
techniques were presented to the world as the only way in which a particular 
challenge ("implementing argumentation systems ...") could be tackled using the 
CRM.  Or are you talking specifically about RDF implementations of the CRM?

Why can't "premises and conclusions" be modelled using reification, so they can 
then be given a unique URI? This is the sort of approach which the BM has 
successfully deployed, as I understand it.  I would be grateful if someone 
could provide a really simple concrete example which shows the need for the 
named graph approach.

To pick up on the suggestion of using the AAT as an example: in what way is the 
AAT a named graph?  Surely it's a SKOS Concept Scheme (plus)?  I think it would 
be impossible to give an example of a "well-known" named graph, for the reasons 
Simon has been explaining.

Richard
On 25/07/2014 20:25, martin wrote:
Dear Richard,

At least in the implementations we use one triple can be in any number of 
graphs, even nested ones
(SESAME, Virtuoso, OWLIM).

The point Steve is making here that Named Graphs are the only way in which 
facts in a database can be
described as explicit content of multiple(!) information objects which are 
described (creation etc.) in the
same system. There is no other choice for implementing argumentation systems 
which explicitly describe
premises and conclusions as propositions in the database.


On 24/7/2014 11:03 πμ, Richard Light wrote:

I must say that I'm not so sure that named graphs are going to be particularly 
useful for implementations of the CRM.  As I understand it (and I don't claim 
to be an RDF expert), the idea of quads was invented so that "naked" RDF 
assertions could be given a "context".  The problem I have always had with that 
idea is that you only get one shot at it (i.e. you can only assign one context 
to any given triple).

Surely (a) we need to be able to express multiple contexts for statements made 
within the CRM, (b) we have already developed a rich enough use of RDF to allow 
us to do so.

Richard
On 24/07/2014 05:57, Simon Spero wrote:

The AAT might work.
I'm not entirely sure that named graphs are propositional objects as defined in 
the CRM, but I think the definition is loose enough.

Named graphs are not graphs that are named; they are a tuple of an IRI (which 
is a name), and graph (which is the set of propositions). If the name is a 
proposition, it is not one in the graph it is associated with.

If Propositional objects can include parts which are not propositions then 
there is no problem- though it would seem more natural to have information 
objects only part of which are propositional.
That would be a bit too  big a change this far down the road ; if named graphs 
can't fit directly, graphs themselves would; these could be part of named 
graphs.
I am not sure if "The encoding structure known as a “named graph” also falls
under this class, so that each “named graph” is an instance of an E73
Information Object." is the right way to say it.

May be better "information encoded as named
graphs may represent instances of E73 Information object including an explicit 
representation of contents".
Since it is an encoding construct, it may represent other things as well. In a 
sense,
it is trivia

Re: [Crm-sig] ISSUE 240: Start/End vs Period of Existence

[Dominic Oldman]

From a slightly more high level perspective I have the following observation 
triggered by something that Martin put in his response but based on a number of 
emails to the list over the last couple of years. Given the increase in the use 
of and interest in the CRM I hope that it is useful.

Cultural Heritage data is multi-layered and highly variable. Curatorial, 
multiple disciplinary perspectives and research requirements contribute to 
these characteristics. The moment that we start to talk about, “there is no 
standard way” or it would be “more economical”, alarm bells are raised. While 
efficiency can be beneficial without being detrimental the desire of 
technologists to standardise cultural heritage data is exactly the reason why 
we need the CRM.

The CRM has been developed precisely to support the fact that you cannot make 
sweeping assumptions across it and that representations must be based on expert 
domain analysis rather than what might be easier for a programmer.  The 
historic quest for standardisation by technologists is a significant factor in 
explaining why many cross-organisational cultural heritage systems have been 
unsuccessful (finally recognised by people who worked on these systems in the 
1990s and resulting in the clear need for the CRM).

Humanities scholars are often disillusioned by computer information systems 
because of the tendency to provide a one-dimensional approach prioritising 
optimisation, performance and ultimately superficially over representing 
knowledge as validly as possible. It is a mistake to think that cultural 
heritage experts want these things in preference to this integrity.  In any 
event it is easy to implement the CRM without compromise (through 
collaboration) and produce highly usable and accessible systems. There is no 
need to artificially standardise the CRM in a way that compromises its raison 
d'etre.

Unless software starts to reflect the methods and understanding that underpin 
the work of cultural heritage researchers and academics (this means that 
computer system experts need to work with and collaborate with humanities 
experts) then it is unlikely that computer systems will contribute 
significantly or realise the promise that those involved in humanities 
computing thought that they might many decades ago.

Dominic
Dominic Oldman
Deputy Head of Information Systems, IS Development Manager,
ResearchSpace Principal Investigator,
British Museum
Sent from Blackberry: 07980865309

From: martin [mailto:mar...@ics.forth.gr]
Sent: Saturday, April 19, 2014 07:38 PM
To: crm-sig@ics.forth.gr 
Subject: Re: [Crm-sig] ISSUE 240: Start/End vs Period of Existence

Hi Vladimir,

Good initiative, but a lot of these things have been discussed in length in
CRM-SIG, and recently we have entered a discussion about start events of 
periods.
I'll point you to respective literature, please have a look at that.

Please do not propose too many things at a time, it makes it difficult to manage
the issue.

In continuation of Stephen: Yes, it is intentional that states that can only be
acquired by explicit events, such as ownership, membership etc., are described
by these events. This is to ensure monotonicity under increase of incomplete,
but consistent knowledge. True life-long observation is extremely rare, 
therefore
most such states are concluded from events. If this is the case, these should be
documented, and not the states. The states should be deductions, and any user
of the CRM is free to introduce such deductions.

"Modeling such Periods of Existence is significantly more economical than 
modeling with Start/End events. "

This is no argument. Firstly, the size of all metadata together are a 
negligible fraction of image
data we keep. Secondly, these events are the hooks for other, distinct, 
historically relevant
information. Birth and death have quite different contexts and actors involved.

Not all periods can have start or end events. Simply, because the event itself 
has
a duration as a fact of physics, and this creates and infinite recursion. To 
define properties
is easy. What we need is an understanding of the semantics of "starting 
something".
Is there an concept of cause or occasion? How does a start event behave in 
space-time?

See in particular:

  1.  Doerr, M., Kritsotaki, A., & Stead, S. (2005). Thesauri of historical 
periods - A proposal for standardization. In Proceedings CIDOC '05 Conference, 
Zagreb, Croatia, 24-27 May.
  2.  Doerr, M., Kritsotaki, A., & Stead, S. (2004). Which Period is it? A 
Methodology to Create Thesauri of Historical Periods. Computer Applications and 
Quantitative Methods in Archaeology Conference, CAA2004, Prato, Italy, 13-17 
April.

"momentary events" are a fiction of computer science. A basic requirement for 
the CRM is that it is
scale-invariant. There is no smallest granularity for events we could easily 
point to.

You write:
"HOWEVER, there

Re: [Crm-sig] Issue 230 Co-reference

[Dominic Oldman]

I don't understand this properly despite reading this email quite a few times.

I have some text contained in a book or on an object that refers to or is about 
a city in Bavaria called Passau.

I have a local knowledge of this place that I have my own identifier for. I can 
therefore co reference the text to my identifier.

Someone else has an identifier for Passau but I don't know for sure whether it 
is taking about the same thing. It is outside my local knowledge.

Is the suggestion that P155 should only be used for co referencing local 
knowledge not external uri outside local knowledge.

Thanks and apologies if this is obvious.

Dominic

PS. Also, if I use Getty places in my local knowledge base I assume that I can 
say that this is local knowledge even though it is an external uri.

Dominic Oldman
Deputy Head of Information Systems, IS Development Manager,
ResearchSpace Principal Investigator,
British Museum
Sent from Blackberry: 07980865309

- Original Message -
From: Øyvind Eide [mailto:lis...@oeide.no]
Sent: Tuesday, April 01, 2014 12:27 AM
To: crm-sig 
Subject: Re: [Crm-sig] Issue 230 Co-reference


On 30. mars 2014, at 21:25, martin wrote:

> Dear Oeyvind,
> 
> On 29/3/2014 10:13 πμ, Øyvind Eide wrote:
>> It is quite possible that I do not understand what you say about P155. So 
>> this is my understanding of it:
>> 
>> Co-reference assignment is about making explicit a fact which is assumed by 
>> the one making the assignment to be true.
> Yes.
>> An example:
>> 
>> I claim that the word "Passau" on my train ticket and the place referred to 
>> by "city where the first DHd conference took place" both refer to the 
>> physical place Passau. If I make this statement in an information system, I 
>> would say:
>> 
>> E91 Co-Reference Assignment P155 has co-reference target P53 Passau.
>> (+ the other properties)
>> 
>> The P155 points to the thing in the world to which the person making the 
>> co-reference assignment believes the references to point to.
> Yes. How do I know that the URI (or whatever the range instance of P155 is) 
> points to the Passau
> I ment when I make this statement? This is why I said,
> "The range of P155 can be interpreted as a URI (or whatever identity) used 
> within the same knowledge base as the instance of E91. Then, it would 
> correspond to a co-reference between some text element and the knowledge base 
> in which we implement the CRM, the "local truth".
> 
> It means, the Co-Reference statement shares the same reality (my 
> understanding of the world )
> as the identifier for "Passau" at p155. In other words, I know by sure how to 
> relate this identifier to
> the City in Bavaria. It could however be, that I refer to a URI for "Passau", 
> which has been imported
> in my knowledge base, and indeed was used for another Passau in another 
> knowledge base which coined the URI. Then, my coref statement would be 
> misleading. Indeed, it would be yet another co-reference, but this time to 
> the use of a URI within a knowledge base, rather than a word within a text.
> 
> All the magic is in your phrase: "The P155 points to the thing in the world". 
> Whose world?
> 
> Therefore, I'd suggest that P155 must point to an identifier of something the 
> person who makes the
> co-ref statement has an unambiguous notion of reality about, either a thing 
> in the world by use
> of an identifier the person "knows" to interpret, or pointing to a 
> hypothetical thing "the thing referred in these two texts, whatever it is". 
> In the latter case, it has an identity condition based on the text.
> In any case, the scope note must make clear what difference is between P155 
> the other links in terms
> of knowing. Therefore I proposed a "local shared truth" for P155.
> 
> Opinions?

Dear Martin,

I think I understand now. But to make it clear if I do:

in a normal reference situation, for instance (to go back to the situation of 
the example in CRM):

E82 Hans Jæger (the name on the title page of the book) P131 identfies E21 Hans 
Jæger (the historical person)

In that case the problem of reference you talk about does not apply.

But in the situation:

E91 Co-Reference Assignment P155 has co-reference target E21 Hans Jæger (the 
historical person)

the problem does arise.

The difference between the two situations is that in the former (P131) the 
reference is expressed in the model, whereas in the latter (P155) the 
references is expressed in a statement recorded in the model.

Right?

The questions is: do we need to record what the person making the co-reference 
statement believes the propositional objects refer to? The reference from each 
of them will/should/may be recorded in the system throught systems such as the 
various "identifies" properties. 


Best,

Øyvind
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] ISSUE

[Dominic Oldman]

I already say in documentation, cultural heritage and beyond.
Dominic Oldman
Deputy Head of Information Systems, IS Development Manager,
ResearchSpace Principal Investigator,
British Museum
Sent from Blackberry: 07980865309

From: Stephen Stead [mailto:ste...@paveprime.com]
Sent: Friday, February 21, 2014 05:03 PM
To: 'martin' ; 'crm-sig' 
Subject: Re: [Crm-sig] ISSUE

I think it should be broadened to “Cultural Heritage” in general.
SdS

Stephen Stead
Tel +44 20 8668 3075
Mob +44 7802 755 013
E-mail ste...@paveprime.com<mailto:ste...@paveprime.com>
LinkedIn Profile http://uk.linkedin.com/in/steads

From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr] On Behalf Of martin
Sent: 17 February 2014 20:14
To: crm-sig
Subject: [Crm-sig] ISSUE

Dear All,

Should we define the practical scope of the CRM wider than "museums" ?
I believe yes:

"the Practical Scope,

which is expressed by the overall scope of a reference set of specific

identifiable museum documentation standards and practices that the CRM aims to

encompass..."





Best,



Martin









--



--

 Dr. Martin Doerr  |  Vox:+30(2810)391625|

 Research Director |  Fax:+30(2810)391638|

   |  Email: 
mar...@ics.forth.gr<mailto:mar...@ics.forth.gr> |

 |

   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   |

 |

 Web-site: http://www.ics.forth.gr/isl   |

--

[Crm-sig] European funding and COST

[Dominic Oldman]

Dear SIG,

Further to Martin’s email, my initial thoughts on the COST action were that, if 
members and supporters of CRM-SIG were going to apply for a European project 
aimed at collaborating with CRM-SIG, then we needed to agree the overall 
objectives that were both within the scope of the fund and that were compatible 
with our own objectives. There may be different opinions about this and these 
need to be considered thoughtfully. 

It seems clear to me from recent emails that there indeed may be different 
views and that further discussion about the approach is necessary. I had not 
seen the email from Vladimir about the approach or agreed an approach with him 
but I will be in the Hague in April to contribute to the discussion and look 
forward to seeing everyone.

 Thanks,

 Dominic
 
Dominic Oldman
Deputy Head of Information Systems, IS Development Manager,
ResearchSpace Principal Investigator,
British Museum
Sent from Blackberry: 07980865309

Re: [Crm-sig] CIDOC-CRM in Australian humanities virtual laboratoryproject: HuNI

[Dominic Oldman]

Dear Ingrid,

This is very exciting news and I am sure that the Crm-sig will be very 
supportive as they have been on the ResearchSpace project.

I look forward to looking at the links you have posted and will pass any 
relevant informations we have to assist you. 

Very best,

Dominic










Dominic Oldman 
Deputy Head of Information Systems, IS Development Manager, 
ResearchSpace Principal Investigator, 
British Museum 
Sent from Blackberry: 07980865309



From: crm-sig-boun...@ics.forth.gr 
To: crm-sig@ics.forth.gr 
Cc: Anne Cregan ; Conal Tuohy 
Sent: Mon Oct 08 00:19:29 2012
Subject: [Crm-sig] CIDOC-CRM in Australian humanities virtual 
laboratoryproject: HuNI 


Hi there,

Was very glad to discover this CIDOC-CRM listserv is thriving and to see this 
tip in my In Box this morning.

Just a brief note to let this list members know that we are looking into 
CIDOC-CRM as a significant component of the HuNI ontology we aim to build 
thanks to some federal funding from NeCTAR 
<http://www.nectar.org.au/humanities-networked-infrastructure-huni-virtual-laboratory>
 .  We are also looking into FRBR-OO and FOAF.  Roles around this part of the 
development are shared: 


*   Dr Anne Cregan <http://www.intersect.org.au/intersect-team#cregan_anne> 
 - interoperability liaison
*   Conal Tuohy <http://versi.edu.au/about-us/versi-team#Con>  - technical 
coordinator
*   Ingrid Mason <http://www.intersect.org.au/intersect-team#mason_ingrid>  
- information services coordinator

The HuNI project website <http://www.huni.net.au/>  is in development, the wiki 
known as 'Apidictor <http://apidictor.huni.net.au/trac/> ' is beginning to fill.

We'd welcome feedback or questions and we will certainly be looking how others 
of you are using CIDOC-CRM.  

Good wishes, Ingrid

-- 
Ingrid Mason | Information Services Coordinator 
Humanities Networked Infrastructure (HuNI) Virtual Laboratory 
huni.versi.edu.au | apidictor.huni.net | #HuNIVL
NeCTAR | www.nectar.org.au 

--
ingrid.ma...@intersect.org.au | www.intersect.org.au | @1n9r1d
T +61 2 8079 2559 | M +61 414 285 232 
Level 12, 309 Kent St, Sydney, NSW 2000, Australia
All mail to: PO Box H58, Australia Square, Sydney NSW 1215, Australia

Re: [Crm-sig] CIDOC-CRM in Australian humanities virtual laboratoryproject: HuNI

[Dominic Oldman]

Dear Ingrid,

This is very exciting news and I am sure that the Crm-sig will be very 
supportive as they have been on the ResearchSpace project.

I look forward to looking at the links you have posted and will pass any 
relevant informations we have to assist you. 









Dominic Oldman 
Deputy Head of Information Systems, IS Development Manager, 
ResearchSpace Principal Investigator, 
British Museum 
Sent from Blackberry: 07980865309



From: crm-sig-boun...@ics.forth.gr 
To: crm-sig@ics.forth.gr 
Cc: Anne Cregan ; Conal Tuohy 
Sent: Mon Oct 08 00:19:29 2012
Subject: [Crm-sig] CIDOC-CRM in Australian humanities virtual 
laboratoryproject: HuNI 


Hi there,

Was very glad to discover this CIDOC-CRM listserv is thriving and to see this 
tip in my In Box this morning.

Just a brief note to let this list members know that we are looking into 
CIDOC-CRM as a significant component of the HuNI ontology we aim to build 
thanks to some federal funding from NeCTAR 
<http://www.nectar.org.au/humanities-networked-infrastructure-huni-virtual-laboratory>
 .  We are also looking into FRBR-OO and FOAF.  Roles around this part of the 
development are shared: 


*   Dr Anne Cregan <http://www.intersect.org.au/intersect-team#cregan_anne> 
 - interoperability liaison
*   Conal Tuohy <http://versi.edu.au/about-us/versi-team#Con>  - technical 
coordinator
*   Ingrid Mason <http://www.intersect.org.au/intersect-team#mason_ingrid>  
- information services coordinator

The HuNI project website <http://www.huni.net.au/>  is in development, the wiki 
known as 'Apidictor <http://apidictor.huni.net.au/trac/> ' is beginning to fill.

We'd welcome feedback or questions and we will certainly be looking how others 
of you are using CIDOC-CRM.  

Good wishes, Ingrid

-- 
Ingrid Mason | Information Services Coordinator 
Humanities Networked Infrastructure (HuNI) Virtual Laboratory 
huni.versi.edu.au | apidictor.huni.net | #HuNIVL
NeCTAR | www.nectar.org.au 

--
ingrid.ma...@intersect.org.au | www.intersect.org.au | @1n9r1d
T +61 2 8079 2559 | M +61 414 285 232 
Level 12, 309 Kent St, Sydney, NSW 2000, Australia
All mail to: PO Box H58, Australia Square, Sydney NSW 1215, Australia

[Crm-sig] Promotion of The CRM

[Dominic Oldman]

Dear SIG,

 

I hope that by using the CRM at the BM it is helpful to CIDOC and the
SIG in promoting the standard. To help with this I have created a blog
on the Museum's rationale for using the CRM on my blog. 

 

http://www.oldman.me.uk/blog/the-british-museum-cidoc-crm-and-the-shapin
g-of-knowledge/

 

Thanks,

 

Dominic

 

 

Dominic Oldman

Deputy Head of IS 

IS Development Manager

ResearchSpace Principal Investigator

British Museum

+44 (0)20 73238796

+44 (0)7980 865309

www.BritishMuseum.org

www.ResearchSpace.org

 

[Crm-sig] working version of BM CRM schema as deep zoom

[Dominic Oldman]

Not finished yet but nearly..

 

http://annotate.oldman.me.uk/semantic/embed.html

 

 

 

Dominic Oldman

Deputy Head of IS 

IS Development Manager

ResearchSpace Principal Investigator

British Museum

+44 (0)20 73238796

+44 (0)7980 865309

www.BritishMuseum.org

www.ResearchSpace.org

 

Re: [Crm-sig] problem of formulating queries is SPARQL it has transferred the old relational paradigm onto the graph structure?

[Dominic Oldman]

Marco,

The search interfaces we are currently developing will be much better than 
relational ones but the practical reality is that Sparql is one of the more 
limiting factors when trying to make the systems accessible. It does seem a bit 
odd than in releasing us from the shackles of RDMS that we model the query 
language on them. 

At  some point those projects developing user applications should get together 
to discuss their practical experiences. But I don't think we need to be 
insecure about questioning things which is fundamental to progress and 
ultimately crucial in building confidence in what we are doing. If we didn't 
question ourselves who would trust us?

Dominic





 
Dominic Oldman
Deputy Head of Information Systems, IS Development Manager,
ResearchSpace Principal Investigator,
British Museum
Sent from Blackberry: 07980865309

- Original Message -
From: crm-sig-boun...@ics.forth.gr 
To: martin 
Cc: crm-sig@ics.forth.gr 
Sent: Thu May 24 20:19:36 2012
Subject: Re: [Crm-sig] problem of formulating queries is SPARQL it has 
transferred the old relational paradigm onto the graph structure?

On Thu, May 24, 2012 at 3:15 PM, martin  wrote:
> Sure, Marco,
>
> I did NOT question SPARQL as an implementation means, even though there are
> very relevant
> and intuitive second order queries that SPARQL cannot answer. I question
> SPARQL as a human-computer
> interface.

And that would be appropriate I would say, but the formulation in the
paper is more fundamental and questions SPARQL as query language for
the Semantic Web in my reading.

>
> Cheers,
>
> Martin
>
>
>
> On 24/5/2012 9:42 μμ, Marco Neumann wrote:
>>
>> Martin,
>>
>> sure, I can see the provocation and obviously fell for it. But you
>> should keep in mind that Linked Data and SPARQL could be or already
>> are major drivers for CIDOC CRM vocabulary adoption in cultural
>> heritage institutions and generally data sets.
>>
>> I hope this thread will help to foster a good conversation around LD
>> and CIDOC CRM. I plan to address the issue again in July.
>>
>> Marco
>>
>> On Thu, May 24, 2012 at 12:11 PM, martin  wrote:
>>>
>>> Hi Marco,
>>>
>>> I am not sure what W3C recommendations have to do with the cognitive
>>> world
>>> experts in the cultural-historical domain.
>>>
>>> But with respect to the statement we made,
>>> nobody in our team, including me, could sufficiently fast understand the
>>> respective
>>> 150 SPARQL queries to verify that they do what was intended.
>>>
>>> I could however put an archaeologist in our team to write queries as
>>> graphs containing
>>> question marks after an hour of training.
>>>
>>> We had implemented very different query paradigms for semantic networks
>>> in the past,
>>> which in our environment turned out to cause less cognitive overload.
>>>
>>> That's just an empirical statement. Generalization are, as always, as
>>> target of criticism.
>>> I would be happy if our provocation would trigger empirical cognitive
>>> research.
>>>
>>> Best,
>>>
>>> Martin
>>>
>>> On 24/5/2012 12:40 μμ, Dominic Oldman wrote:
>>>>
>>>> Hi Marco,
>>>>
>>>> As Sebastian says, we have to use SPARQL. However, just because it is
>>>> the W3C standard doesn't mean you can't criticise it. However, just like
>>>> with SQL we are all looking at ways to help museum practitioners (does
>>>> this include our curators undertaking digital research projects) explore
>>>> data effectively, transparently and with reproducibility, and making use
>>>> of the technology with something additional to the SPARQL Endpoint (this
>>>> lack of additional tools perhaps explaining lack of take up).
>>>>
>>>> The ICOM statement,
>>>>
>>>> "Alternative Proposal for an ICOM-CIDOC Resolution on URIs for Museum
>>>> Objects / Linked Open Data", is more high level statement and the
>>>> statement that we are currently being asked to agree. It doesn't mention
>>>> SPARQL.
>>>>
>>>> Best,
>>>>
>>>> Dominic
>>>>
>>>> Dominic Oldman
>>>> Deputy Head of IS
>>>> IS Development Manager
>>>> ResearchSpace Principal Investigator
>>>> British Museum
>>>> +44 (0)20 73238796
>>>> +44 (0)7980 865309
>>>> www.BritishMuseum.org
>>>> www.ResearchSpace.org
>

Re: [Crm-sig] problem of formulating queries is SPARQL it has transferred the old relational paradigm onto the graph structure?

[Dominic Oldman]

Marco,

I do understand the concern regarding winning over hearts and minds
which has been difficult. I think the best way is to provide good sites
and applications which do the things that museum's have wanted to do for
a long time. We have CLAROS and other projects and I think there will be
some very interesting practical developments (we are working on cultural
data harmonisation and federation) over the summer which will create
more interest, momentum and some new museum SPARQL Endpoints! 

D




Dominic Oldman
Deputy Head of IS 
IS Development Manager
ResearchSpace Principal Investigator
British Museum
+44 (0)20 73238796
+44 (0)7980 865309
www.BritishMuseum.org
www.ResearchSpace.org


-Original Message-
From: Marco Neumann [mailto:marco.neum...@gmail.com] 
Sent: 24 May 2012 10:59
To: Dominic Oldman
Cc: crm-sig
Subject: Re: [Crm-sig] problem of formulating queries is SPARQL it has
transferred the old relational paradigm onto the graph structure?

Dominic, Sebastian,

I am certainly in favor of a discussion and the development of easy to
use query forms but that said I am currently equally in favor of
SPARQL to query RDF data stores.

Higher level abstractions, BTW any app on top of SPARQL that is, are
highly desirable. But knowing our "clients" in cultural heritage
organizations an unqualified statement such as the one made above in
the paper will further to hamper adoption, I would think. It's like
critizing SPARQL as the wrong choice for FOL reasoning tasks which are
not it's primary intended use case. Though SPARQL update is actually a
very efficient tool to approximate the semantics of such goals.

Marco



On Thu, May 24, 2012 at 5:40 AM, Dominic Oldman
 wrote:
> Hi Marco,
>
> As Sebastian says, we have to use SPARQL. However, just because it is
> the W3C standard doesn't mean you can't criticise it. However, just
like
> with SQL we are all looking at ways to help museum practitioners (does
> this include our curators undertaking digital research projects)
explore
> data effectively, transparently and with reproducibility, and making
use
> of the technology with something additional to the SPARQL Endpoint
(this
> lack of additional tools perhaps explaining lack of take up).
>
> The ICOM statement,
>
> "Alternative Proposal for an ICOM-CIDOC Resolution on URIs for Museum
> Objects / Linked Open Data", is more high level statement and the
> statement that we are currently being asked to agree. It doesn't
mention
> SPARQL.
>
> Best,
>
> Dominic
>
> Dominic Oldman
> Deputy Head of IS
> IS Development Manager
> ResearchSpace Principal Investigator
> British Museum
> +44 (0)20 73238796
> +44 (0)7980 865309
> www.BritishMuseum.org
> www.ResearchSpace.org
>
>
> -Original Message-
> From: crm-sig-boun...@ics.forth.gr
[mailto:crm-sig-boun...@ics.forth.gr]
> On Behalf Of Marco Neumann
> Sent: 24 May 2012 10:04
> To: crm-sig
> Subject: [Crm-sig] problem of formulating queries is SPARQL it has
> transferred the old relational paradigm onto the graph structure?
>
> Hi Martin et al
>
> I have just learned about this submission to Museums and the Web. The
> authors make the following statement:
>
> "Last but not least, another problem of formulating queries is SPARQL
> (SPARQL Protocol and RDF Query Language). Most favored by information
> technology (IT) experts, it has transferred the old relational
> paradigm onto the graph structure of the Semantic Web, creating an
> incredibly complex system, even for specialists. In our applications,
> no IT expert was able to verify that a SPARQL query of the kind we
> present in this paper will yield the results intended by a domain
> expert simply by reading it." *
>
> *
> A New Framework for Querying Semantic Networks - Museums and the Web
> 2012
>
http://www.museumsandtheweb.com/mw2012/papers/a_new_framework_for_queryi
> ng_semantic_networks
>
> I find this to be a misleading statement by the authors since SPARQL
> is the recommendation by W3C to query RDF data. Would you not
> recommend SPARQL to museum practitioners to query RDF data?
>
> Regards,
> Marco
>
>
>
> ---
> Marco Neumann
> KONA
>
> Join us at SemTech Biz in San Francisco June 3-7 2012 and save 15%
> with the lotico community discount code 'STMN'
> http://www.lotico.com/evt/SemTechSF2012/
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig



-- 


---
Marco Neumann
KONA

Join us at SemTech Biz in San Francisco June 3-7 2012 and save 15%
with the lotico community discount code 'STMN'
http://www.lotico.com/evt/SemTechSF2012/

Re: [Crm-sig] problem of formulating queries is SPARQL it has transferred the old relational paradigm onto the graph structure?

[Dominic Oldman]

Hi Marco,

As Sebastian says, we have to use SPARQL. However, just because it is
the W3C standard doesn't mean you can't criticise it. However, just like
with SQL we are all looking at ways to help museum practitioners (does
this include our curators undertaking digital research projects) explore
data effectively, transparently and with reproducibility, and making use
of the technology with something additional to the SPARQL Endpoint (this
lack of additional tools perhaps explaining lack of take up).

The ICOM statement,

"Alternative Proposal for an ICOM-CIDOC Resolution on URIs for Museum
Objects / Linked Open Data", is more high level statement and the
statement that we are currently being asked to agree. It doesn't mention
SPARQL.

Best,

Dominic

Dominic Oldman
Deputy Head of IS 
IS Development Manager
ResearchSpace Principal Investigator
British Museum
+44 (0)20 73238796
+44 (0)7980 865309
www.BritishMuseum.org
www.ResearchSpace.org


-Original Message-
From: crm-sig-boun...@ics.forth.gr [mailto:crm-sig-boun...@ics.forth.gr]
On Behalf Of Marco Neumann
Sent: 24 May 2012 10:04
To: crm-sig
Subject: [Crm-sig] problem of formulating queries is SPARQL it has
transferred the old relational paradigm onto the graph structure?

Hi Martin et al

I have just learned about this submission to Museums and the Web. The
authors make the following statement:

"Last but not least, another problem of formulating queries is SPARQL
(SPARQL Protocol and RDF Query Language). Most favored by information
technology (IT) experts, it has transferred the old relational
paradigm onto the graph structure of the Semantic Web, creating an
incredibly complex system, even for specialists. In our applications,
no IT expert was able to verify that a SPARQL query of the kind we
present in this paper will yield the results intended by a domain
expert simply by reading it." *

*
A New Framework for Querying Semantic Networks - Museums and the Web
2012
http://www.museumsandtheweb.com/mw2012/papers/a_new_framework_for_queryi
ng_semantic_networks

I find this to be a misleading statement by the authors since SPARQL
is the recommendation by W3C to query RDF data. Would you not
recommend SPARQL to museum practitioners to query RDF data?

Regards,
Marco



---
Marco Neumann
KONA

Join us at SemTech Biz in San Francisco June 3-7 2012 and save 15%
with the lotico community discount code 'STMN'
http://www.lotico.com/evt/SemTechSF2012/
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig