Re: [Crm-sig] Official NameSpaces of CRM Extensions?

[Nicola Carboni via Crm-sig]

Dear George,

The namespace to be used should be the `xml:base` value in the RDF 
document. Example:

```xml
http://www.w3.org/1999/02/22-rdf-syntax-ns#; 
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#; xml:lang="en" 
xml:base="http://www.cidoc-crm.org/cidoc-crm/CRMsci/;>

```
```xml
http://www.w3.org/1999/02/22-rdf-syntax-ns#; 
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#; 
xml:base="http://www.ics.forth.gr/isl/CRMgeo/; xml:lang="en">

```

The confusion started because the namespace has changed over time

CRMdig 3.2.2 had

```xml
http://www.w3.org/1999/02/22-rdf-syntax-ns#; 
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#; 
xml:base="http://www.ics.forth.gr/isl/CRMext/CRMdig.rdfs/; 
xml:lang="en">

```
The latest version is
```xml
rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#; 
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#; 
xml:base="http://www.ics.forth.gr/isl/CRMdig/; xml:lang="en">

```

Generally they are both documented in [prefix.cc](http://prefix.cc), 
hence someone is still using the old ones.



For clarifying the confusion, It is possible to write explicitly in the 
RDF itself the preferred namespace and prefix, using the properties 
vann:preferredNamespaceUri and vann:preferredNamespacePrefix . Example 
(in ttl) from [VIR](http://prefix.cc) :


```ttl
vann:preferredNamespacePrefix "vir" ;
vann:preferredNamespaceUri "http://w3id.org/vir#; ;
```

Best,

Nicola



--
Nicola Carboni
Visual Contagions
Digital Humanities - dh.unige.ch
Faculté des Lettres
Université de Genève
5, rue de Candolle
1211 Genève 4

On 15 Dec 2021, at 11:58, George Bruseker via Crm-sig wrote:


Dear all,

I am wondering if anybody else struggles with what official namespace 
ot
use for the CRM extensions. I'm not really sure how the situation 
stands.
Should the minisites for each extension have a prominent place where 
they
display the namespaces just so we all follow the same procedure? Do I 
miss

what is already there?

Best,

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

Re: [Crm-sig] Proposal/though: Add URLs to official documentation

[Nicola Carboni via Crm-sig]

Dear all,

Normally the link to the description already exists, but they only use 
property/classes number and they reflect CIDOC-CRM version 5.0.4


In fact, if you go to
http://www.cidoc-crm.org/cidoc-crm/P2
you should be able to see an html version of the property description 
relative to P2 has type.


I noticed in the website that at the moment we can also point to the xml 
version of the documentation (which also use only property/classes 
number for the link). For example:
http://cidoc-crm.org/versions/cidoc_crm_v7.1.1.xml#P2 points to the 
documentation of the property P2_has_type as described in version 7.1.1 
of the documentation.


A simple solution would be to just redirect from the uri of a 
class/property to to the latest XML.
Example: http://www.cidoc-crm.org/cidoc-crm/P2_has_type should redirect 
to the property description in the last version available of the 
documentation (http://cidoc-crm.org/versions/cidoc_crm_v7.1.1.xml#P2). 
Redirect should also be established for the property only present in RDF 
(e.g. P81a/P81b)



However, that opens up the problem of versioning. CIDOC-CRM in respect 
to many other ontologies is quite dynamic, so definitions changes and 
classes are added (or deleted) in time. The very first problem that come 
to mind is relative to the classes which have been deleted (e.g. 
Retrieve the scope note of E38 not knowing that it was deleted in 
version 6.2.9). However, even for the classes which have simply changed 
scope note, should we redirect to one specific version of the ontology 
(therefore reflecting the definition of that class in a specific moment 
in time when it was used) or simply point to the current one?


Because in case of the former solution, the namespace uri should include 
the version of CIDOC-CRM..




Best,

Nicola



--
Nicola Carboni
Visual Contagion
Digital Humanities - dh.unige.ch
Faculté des Lettres
Université de Genève
5, rue de Candolle
1211 Genève 4

On 26 Jul 2021, at 14:02, George Bruseker via Crm-sig wrote:


Dear all,

Thanks for your feedback on this. So it sounds like there is interest 
in

discussing this as an issue in the next SIG.

The proposal that was in my mind was that the specification document 
(the
word/pdf) would also have the URL/I as a hotlink in the documentation 
of
the class or property and that if you clicked this it would bring you 
to
the server which would guide you to the definition of the class in 
some
structured format be that RDFS or OWL or the detailed documentation 
format

on the website:
http://www.cidoc-crm.org/Entity/E3-Condition-State/version-7.1.1 .

But there may be other perceptions or ideas around the best way of
including this conveniently and where.

Best,

George

On Tue, Jul 20, 2021 at 8:03 PM Athanasios Velios via Crm-sig <
crm-sig@ics.forth.gr> wrote:

I agree with this. Shouldn't it be part of the RDF implementation 
document?


Thanasis

On 20/07/2021 15:37, Robert Sanderson via Crm-sig wrote:


Wholehearted agreement. Even if they're expressed in different ways 
by
different representations of the conceptual model, if we can 
standardize

the URI then an RDFS description and an OWL description of *the same
URIs* can be used by different communities without breaking
interoperability. If we get RDF*, or other declarative technological
models for describing graph structures, then they too could describe 
the

use of the URIs in their contexts.

Rob

On Tue, Jul 20, 2021 at 6:03 AM George Bruseker via Crm-sig
mailto:crm-sig@ics.forth.gr>> wrote:

Dear all,

Many people try to use the CIDOC CRM in order to build 
sustainable,
reusable data sources and connect into a wider linked open data 
web.


When they do so, they would like to easily be able to find / use 
the

URIs for the classes and properties that the standard declares.

The official documentation does not include this information in 
a

handy way.

Proposal for discussion: include the URIs for the classes and
properties as clickable links that resolve to the online space 
where

they are maintained in the word/pdf specification.

Discuss!

Best,

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




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


___
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 mailing list
Crm-sig@ics.forth.gr

Re: [Crm-sig] Modelling 'Transcription' Advice?

[Nicola Carboni via Crm-sig]

Dear George, all,

As Martin pointed out CRMtext surely provide a solutions (there is 
indeed a class transcription), however in the past I found myself using 
the same modelling that Rob proposed (using P2 instead of P32 on the 
activity node)



Best,

Nicola


--
Nicola Carboni
Visual Contagion
Digital Humanities - dh.unige.ch
Faculté des Lettres
Université de Genève
5, rue de Candolle
1211 Genève 4

On 22 Jul 2021, at 17:08, Martin Doerr via Crm-sig wrote:


Dear Rob, All,

I think this is a question to CRMtex, and Achille and Francesca, which 
should provide a general theory of transcriptions.


All the best,

martin

On 7/22/2021 4:59 PM, Robert Sanderson via Crm-sig wrote:


What about:

 A a E33_Linguistic_Object ;
  P94i_was_created_by Creation .
Creation a E65_Creation ;
  p2_has_type or p32_used_general_technique  ;
  p16_used_specific_object B .

Rob



On Tue, Jul 20, 2021 at 5:58 AM George Bruseker via Crm-sig 
mailto:crm-sig@ics.forth.gr>> wrote:


Dear all,

Just a general question to the crowd.

Sometimes one has transcribed data of a very simple form.

A is supposed to represent B and it has been copied by someone
with the intention of so doing.

A is a transcription of B

A [E33] is a transcription of B [E33]

This could be modelled numerous ways using CIDOC CRM. If one is
looking for the most direct/binary way, I suppose that the only
choice is "p130 shows features of". If you wanted to capture the
mode of relation then you would use p130.1 has type and indicate
'transcription'.

I notice, however, that we do have 'has translation' as a sub
property of P130 shows features of, as an apparently useful to 
the

community binary property specializing P130 to that specific
scenario.

Has anyone else done modelling of transcriptions before with the
aim of not recording the event but only the binary relation and 
if

so, did you come up with any interesting solutions?

A property would be handy in case anyone has created and 
published

a specialization that could just be reused?

Thanks for any insight! Maybe I miss an obvious trick from LRM?

All the best,

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




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



--

 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

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

[Nicola Carboni via Crm-sig]

Dear all,

In the context of the homework for this issue I report a bit of 
information about way to make statements about triples.


During the last conversation on the issue, I believe we did discuss the 
usefulness of formalising a way to talk about named graph. The 
conversation was born, if I remember correctly, from the survey made by 
GB about how we use named graphs and if we should standardise a way to 
do so.


I enlarge a bit the problem, as in my perspective what we are seeking to 
standardise, it is not only named graph but ways to talk about 
statements.


Currently, there are several RDF-based approaches to talk about 
statements, mainly: named graph, rdf-star and classic reification 
methods[1].


Named graph is the classical approach to group together a series of RDF 
statements and (possibly) make further statements about it. It extended 
standard RDF with a fourth element, an IRI, which is used to identify an 
RDF graph (the result is a quadruples). Named graph can be used in 
several ways and for several purpose as there is no attached semantics 
to them. They are used by systems to store technical data about the 
graph database itself, as well as a way to differentiate and group 
statements together. There is really not so much limit to their uses and 
they are just a mechanism of grouping statements together and made them 
identifiable.


Lately, RDF-star (ex RDF*) has been also proposed as another way to make 
statements about statements. RDF-star is a novel way, not yet W3C 
officially approved, to make statements about triples. While not 
officially approved, it is implemented and working across several graph 
databases. RDF-star started from the basic idea that should be possible 
to make statements about a single triple using a simple syntax, such as:


`<<>> :assertedBy :Person `

Above, two statements are encoded: it exists a triple `  ` and 
that triple is asserted by :Person


so we have a first triple:

subject: ``
predicate: ``
object: ``

and a second triple:

subject: `  `
predicate `:assertedBy`
object: `:Person`

the operator `<<` `>>` are used to identify a triple which is used as 
subject or object of a RDF statement.
RDF-star can be recursive and used to nest more statements together and 
say, for example:


`<< <<>> :assertedBy :Person >> :source :uri  >>`

where three statements appear, that exist a triple `  `, that 
is is asserted by :Person and the source for such statement is to be 
found in a :uri.



A translation these last statements using a single-statement named graph 
would be:


```
   <#assertion1>
<#assertion1> :assertedBy :Person
<#assertion1> :source :uri
```


so what are the difference between the methods:

1. Named graph do not have any semantics attached to it. the lack of 
semantics in named graphs implies that statements about the graph do not 
really have to be about the content of the graph. For as much as it 
could be intuitive, it is not formally defined.

2. Named graph need identifier as proxy (so additional node)
3. Named graph are part of RDF 1.1 standards
4. RDF-star will be more aligned with property graph
5. RDF-star do not need identifier to define a graph
7. RDF-star are used for single-level statement, nor for annotating 
graphs (as in named graph)
8. RDF-star reuse and can be (in theory) completely aligned with RDF 
semantic.
9. The semantics of RDF-star differentiate between asserted and embedded 
triples

10. The semantics of RDF is referential opaque (if I remember correctly)


Both methods can be used to talk and make statements about triples. Is 
any of this useful? To me, very.


For example, In our current project, Visual Contagion, we are working 
towards the use of historical record (and computed visual similarity) 
that tell us about contact between artists and works of art to define 
possible visual transfers. We would like to differentiate between 
statements that have as source historical records, information derived 
from computed visual similarities and clustering, and interpretations 
based on these initial records. We will use named graphs for recording 
possible influences, and document the chain of information and sources 
behind an interpretations.


Another clear example of use on named graph in the past has been the 
recording of misattribution in paintings, and how their attribution has 
changed over time.


In both case, named graph were the tools we used to make statements 
about statements, but as mentioned above, there are other ways, and 
maybe in the future I will try to test RDF-star, or on property graph.


I would, therefore, not focus on the formalisation of named graph, but 
on the clarification/documentation of the way we talk about triples in 
CRM, how we can encode such information and mostly what is their 
context/validity. For example, RDF-start allow for the differentiation 
of asserted and embedded triples, making evident the context in which a 
triple is valid, while named 

Re: [Crm-sig] Issue:530 Bias in the CRM

[Nicola Carboni via Crm-sig]

Dear Thanasis, all,


I would be happy to join the discussion. Another useful reading other 
than the already cited ones, is ["Cataloguing Culture: Legacies of 
Colonialism in Museum 
Documentation”](https://www.ubcpress.ca/cataloguing-culture) by Hannah 
Turner.


Regarding the name and the scope of the issue: should we focus on data 
structure (I see the title of the issue is "bias in data structure") or 
specifically on ontologies and CRM?
While I do very much believe that data structure is an enormously 
important topic to discuss, it is an extremely large subject, and entail 
a larger series of problems which do derive from the informational 
foundation, the concept of structure itself, the recorded information, 
as well as disciplinary inheritance in the chosen subject matter.


I second rob proposing to focus on the problem of the ontology and the 
process of documentation/development. I would add that we should include 
some point about CRM as system of thought as well as the problem of 
formalisation.



* Implementations and Instances of the Ontology
 -- I think these are useful as second-order evidence, but that we 
should not be too involved or prescriptive.


I would include the topic, as to make clear the diversity in 
implementation (use of terminological systems as well as the use of the 
concept of controlled terminology itself), avoiding indeed the 
prescriptive stance.



Best,

Nicola


P.s. Great initiative :-)



On 8 Mar 2021, at 21:33, Athanasios Velios via Crm-sig wrote:

Thank you Erin. We are using Zotero already for the CRM so this is a 
good idea. I can check if a new folder can be created for issue 530.


T.


On 08/03/2021 19:01, Erin Canning wrote:
I would also like to be involved in this discussion, please! I too 
have a reading list on the subject that I would be happy to share; I 
have been meaning to pull everything into a Zotero library and this 
is a good excuse to do so. For a single article to start things off, 
I would recommend Miriam Posner's "What's Next: The Radical, 
Unrealized Potential of the Digital Humanities" 
 
as an interesting read.


Best,
Erin


Erin Canning

canni...@uoguelph.ca
Ontology Systems Analyst, LINCS
https://lincsproject.ca/



*From:* Crm-sig  on behalf of 
Athanasios Velios via Crm-sig 

*Sent:* March 8, 2021 12:52 PM
*To:* crm-sig 
*Subject:* Re: [Crm-sig] Issue:530 Bias in the CRM
EXTERNAL EMAIL:

Fantastic! Thank you for sharing and you are first in the list.

For the rest in list and if you did not attend today's sessions,
following discussion for issue 530, a working group is being formed 
to
discuss bias in the CRM. Please let me know if you wish to contribute 
to

the discussion.

All the best,

Thanasis

On 08/03/2021 17:17, Anaïs Guillem wrote:

Dear Thanasis, all,
Some digital humanists work and publish on this question of bias in
digital humanities: here is an example of very a propos publication:

https://journals.dartmouth.edu/cgi-bin/WebObjects/Journals.woa/xmlpage/4/article/425



>


I gathered myself bibliography about decolonizing knowledge and
methodology especially in digital project. I could join the 
discussion

of your working group if you want.
Cheers,
Anais

Le mer. 3 mars 2021 à 14:58, Athanasios Velios 
>> a 
écrit :


 Dear all,

 In version 7.1 a short but important sentence has been 
added at the end

 of the scope section:

 "Discussions on the types of bias present in the CIDOC CRM 
are in

 progress within the CIDOC CRM community."

 Issue 530 is used to track the discussions here:

http://cidoc-crm.org/Issue/ID-530-bias-in-data-structure



 >


 It is important to engage in this discussion so that we 
first understand
 the issues around bias and privileged positions and then 
how these may

 or may not impact the development of the model.

 We will then be more confident in making a more complete 
statement is
 future versions. Issue 530 is scheduled to be discussed at 
the community

 session of the forthcoming meeting.

 Looking forward to it.

 All the best,

 Thanasis
 ___
 Crm-sig mailing list
 Crm-sig@ics.forth.gr >