Re: [Crm-sig] Argument for an Instrument Class (and its property)

[Øyvind Eide via Crm-sig]

Really interesting distinction. When doing pre-digital surveys for maps we used 
the compass for direction (clearly an instrument, and active?) and bodily 
calibrated steps to count the meters of distances (clearly part of the human 
body). Still the results of these measurements were more or less equally 
(in)accurate and were recorded in a similar way (pencil on transparent paper). 

Can we define by function? Are instruments just anything used for measurements? 
Neat solution but will lead to quite counter-intuitive claims I fear. 

I am sure the homework will lead to some further questions, hopefully bringing 
us further. 

Regards,

Øyvind

> Am 07.09.2021 um 22:14 schrieb Martin Doerr via Crm-sig 
> :
> 
> Great!  Critical question: What constitutes a single instrument, and where do 
> we draw a line to tools? I'd argue that one measurement instrument should be 
> able to yield a quantitative result, and be a sort of "black box" integrated 
> device, such as the sequencing machines.
> 
> Question: yardsticks are "passive". Are they still instruments, even though 
> the human eye is the instrument? I think they are a different category of 
> calibrated objects for comparing, such as color charts etc.
> 
> Cheers,
> 
> Martin 
> 
> On 9/7/2021 8:11 PM, Robert Sanderson wrote:
>> 
>> I'm happy to take a homework to write up DNA measurement with CRM and 
>> Instruments in mind :)
>> 
>> [My wife used to work for Illumina , and then for 
>> one of their biggest customers, and was part of the team that discovered the 
>> markers that led to Grail ]
>> 
>> Rob
>> 
>> 
>> On Tue, Sep 7, 2021 at 12:47 PM Martin Doerr via Crm-sig 
>> mailto:crm-sig@ics.forth.gr>> wrote:
>> Dear All,
>> 
>> Just to give you a picture of the diversity and complexity we discuss.
>> 
>> Probably the high-end in complexity is a DNA - taxonomic distance 
>> measurement, a procedure, even though straightforward and deterministic, 
>> as I understand, with an great number of steps, a series of instruments 
>> subsequently used and possible errors in each one.
>> 
>> Interesting also a LIPS / Raman analysis of painting colorants, which 
>> uses multiple instruments until the final result,  not reliably 
>> quantitative and including assumptions about a limited set of possible 
>> colorants that might be wrong.
>> 
>> As the most simple ones we may have yard sticks, but the most exotic in 
>> simplicity I can think of are pyrometric cones. They are used worldwide 
>> to monitor ceramic firings in industrial kilns, pottery kilns, for a 
>> one-time measurement of the maximum temperature reached by firing a 
>> kiln. They are calibrated to one temperature only, but normally 
>> destroyed by the measurement.
>> 
>> What is "one instrument", and are pyrometric cones and yardsticks 
>> instruments? What about body parts (ells, feet)
>> 
>> Best
>> 
>> Martin
>> 
>> On 9/6/2021 1:59 PM, Athanasios Velios via Crm-sig wrote:
>> > I think this would be a useful discussion and class. It has also been 
>> > proposed within the PARCOURS model although perhaps a tighter proposal 
>> > can be made.
>> >
>> > Thanasis
>> >
>> > P.S. The example for P103 could do with updating...
>> >
>> > On 01/09/2021 20:47, Martin Doerr via Crm-sig wrote:
>> >> Hi George,
>> >>
>> >> I think this is a good idea, of course, we should first look at a 
>> >> more specific property, since "instruments" can be very 
>> >> heterogeneous, or we concentrate on measurement devices in a narrower 
>> >> sense.
>> >>
>> >> Best,
>> >>
>> >> Martin
>> >>
>> >> On 8/25/2021 12:53 PM, George Bruseker via Crm-sig wrote:
>> >>> Dear all,
>> >>>
>> >>> I am working on a conservation science modelling project in which 
>> >>> the users document also their machinery. Something that comes up is 
>> >>> that they want to document the kind of property or variable that is 
>> >>> measured by the machine. This is a property of the machine, what it 
>> >>> can do (dunamis).
>> >>>
>> >>> We of course already have p103 was intended for
>> >>> http://www.cidoc-crm.org/Property/P103-was-intended-for/version-7.1.1 
>> >>>  
>> >>> > >>> >
>> >>>
>> >>> I already make use of this for the purpose of documenting the 
>> >>> general kind of method the machine can be used for.
>> >>>
>> >>> But when you run the machine, it tests for certain variables and 
>> >>> produces a resulting output which is a digital record of a signal 
>> >>> carrying that variable.
>> >>>
>> >>> This reminds me of some elements from CRMSci and from CRMdig
>> >>>
>> >>> CRMSci has observations that look for property types:
>> >>>
>> >>> S4 Observation
>> >>> O9 observed property type E55
>> >>>
>> >>> http://www.cidoc-crm.org/crmsci/sites/default/files/CRMsci%20v.1.3.

Re: [Crm-sig] Argument for an Instrument Class (and its property)

[Martin Doerr via Crm-sig]

Great!  Critical question: What constitutes a single instrument, and 
where do we draw a line to tools? I'd argue that one measurement 
instrument should be able to yield a quantitative result, and be a sort 
of "black box" integrated device, such as the sequencing machines.


Question: yardsticks are "passive". Are they still instruments, even 
though the human eye is the instrument? I think they are a different 
category of calibrated objects for comparing, such as color charts etc.


Cheers,

Martin

On 9/7/2021 8:11 PM, Robert Sanderson wrote:


I'm happy to take a homework to write up DNA measurement with CRM and 
Instruments in mind :)


[My wife used to work for Illumina , and 
then for one of their biggest customers, and was part of the team that 
discovered the markers that led to Grail ]


Rob


On Tue, Sep 7, 2021 at 12:47 PM Martin Doerr via Crm-sig 
mailto:crm-sig@ics.forth.gr>> wrote:


Dear All,

Just to give you a picture of the diversity and complexity we discuss.

Probably the high-end in complexity is a DNA - taxonomic distance
measurement, a procedure, even though straightforward and
deterministic,
as I understand, with an great number of steps, a series of
instruments
subsequently used and possible errors in each one.

Interesting also a LIPS / Raman analysis of painting colorants, which
uses multiple instruments until the final result,  not reliably
quantitative and including assumptions about a limited set of
possible
colorants that might be wrong.

As the most simple ones we may have yard sticks, but the most
exotic in
simplicity I can think of are pyrometric cones. They are used
worldwide
to monitor ceramic firings in industrial kilns, pottery kilns, for a
one-time measurement of the maximum temperature reached by firing a
kiln. They are calibrated to one temperature only, but normally
destroyed by the measurement.

What is "one instrument", and are pyrometric cones and yardsticks
instruments? What about body parts (ells, feet)

Best

Martin

On 9/6/2021 1:59 PM, Athanasios Velios via Crm-sig wrote:
> I think this would be a useful discussion and class. It has also
been
> proposed within the PARCOURS model although perhaps a tighter
proposal
> can be made.
>
> Thanasis
>
> P.S. The example for P103 could do with updating...
>
> On 01/09/2021 20:47, Martin Doerr via Crm-sig wrote:
>> Hi George,
>>
>> I think this is a good idea, of course, we should first look at a
>> more specific property, since "instruments" can be very
>> heterogeneous, or we concentrate on measurement devices in a
narrower
>> sense.
>>
>> Best,
>>
>> Martin
>>
>> On 8/25/2021 12:53 PM, George Bruseker via Crm-sig wrote:
>>> Dear all,
>>>
>>> I am working on a conservation science modelling project in which
>>> the users document also their machinery. Something that comes
up is
>>> that they want to document the kind of property or variable
that is
>>> measured by the machine. This is a property of the machine,
what it
>>> can do (dunamis).
>>>
>>> We of course already have p103 was intended for
>>>
http://www.cidoc-crm.org/Property/P103-was-intended-for/version-7.1.1


>>>
>
>>>
>>> I already make use of this for the purpose of documenting the
>>> general kind of method the machine can be used for.
>>>
>>> But when you run the machine, it tests for certain variables and
>>> produces a resulting output which is a digital record of a signal
>>> carrying that variable.
>>>
>>> This reminds me of some elements from CRMSci and from CRMdig
>>>
>>> CRMSci has observations that look for property types:
>>>
>>> S4 Observation
>>> O9 observed property type E55
>>>
>>>
http://www.cidoc-crm.org/crmsci/sites/default/files/CRMsci%20v.1.3.pdf


>>>
>
>>>
>>> We also have in CRMdig both a class for instruments (digital ones)
>>>
>>> D8 Digital Device
>>>
>>> and we again have a notion of an observation kind of event
measuing
>>> a kind of thing
>>>
>>> D11 Digital Measurement Event
>>> L17 measured thing of type E55
>>>
>>>
http://www.cidoc-crm.org/crmdig/sites/default/files/CRMdig_v3.2.1.pdf

Re: [Crm-sig] Argument for an Instrument Class (and its property)

[Robert Sanderson via Crm-sig]

I'm happy to take a homework to write up DNA measurement with CRM and
Instruments in mind :)

[My wife used to work for Illumina , and then
for one of their biggest customers, and was part of the team that
discovered the markers that led to Grail ]

Rob


On Tue, Sep 7, 2021 at 12:47 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear All,
>
> Just to give you a picture of the diversity and complexity we discuss.
>
> Probably the high-end in complexity is a DNA - taxonomic distance
> measurement, a procedure, even though straightforward and deterministic,
> as I understand, with an great number of steps, a series of instruments
> subsequently used and possible errors in each one.
>
> Interesting also a LIPS / Raman analysis of painting colorants, which
> uses multiple instruments until the final result,  not reliably
> quantitative and including assumptions about a limited set of possible
> colorants that might be wrong.
>
> As the most simple ones we may have yard sticks, but the most exotic in
> simplicity I can think of are pyrometric cones. They are used worldwide
> to monitor ceramic firings in industrial kilns, pottery kilns, for a
> one-time measurement of the maximum temperature reached by firing a
> kiln. They are calibrated to one temperature only, but normally
> destroyed by the measurement.
>
> What is "one instrument", and are pyrometric cones and yardsticks
> instruments? What about body parts (ells, feet)
>
> Best
>
> Martin
>
> On 9/6/2021 1:59 PM, Athanasios Velios via Crm-sig wrote:
> > I think this would be a useful discussion and class. It has also been
> > proposed within the PARCOURS model although perhaps a tighter proposal
> > can be made.
> >
> > Thanasis
> >
> > P.S. The example for P103 could do with updating...
> >
> > On 01/09/2021 20:47, Martin Doerr via Crm-sig wrote:
> >> Hi George,
> >>
> >> I think this is a good idea, of course, we should first look at a
> >> more specific property, since "instruments" can be very
> >> heterogeneous, or we concentrate on measurement devices in a narrower
> >> sense.
> >>
> >> Best,
> >>
> >> Martin
> >>
> >> On 8/25/2021 12:53 PM, George Bruseker via Crm-sig wrote:
> >>> Dear all,
> >>>
> >>> I am working on a conservation science modelling project in which
> >>> the users document also their machinery. Something that comes up is
> >>> that they want to document the kind of property or variable that is
> >>> measured by the machine. This is a property of the machine, what it
> >>> can do (dunamis).
> >>>
> >>> We of course already have p103 was intended for
> >>> http://www.cidoc-crm.org/Property/P103-was-intended-for/version-7.1.1
> >>>  >
> >>>
> >>> I already make use of this for the purpose of documenting the
> >>> general kind of method the machine can be used for.
> >>>
> >>> But when you run the machine, it tests for certain variables and
> >>> produces a resulting output which is a digital record of a signal
> >>> carrying that variable.
> >>>
> >>> This reminds me of some elements from CRMSci and from CRMdig
> >>>
> >>> CRMSci has observations that look for property types:
> >>>
> >>> S4 Observation
> >>> O9 observed property type E55
> >>>
> >>> http://www.cidoc-crm.org/crmsci/sites/default/files/CRMsci%20v.1.3.pdf
> >>> <
> http://www.cidoc-crm.org/crmsci/sites/default/files/CRMsci%20v.1.3.pdf>
> >>>
> >>> We also have in CRMdig both a class for instruments (digital ones)
> >>>
> >>> D8 Digital Device
> >>>
> >>> and we again have a notion of an observation kind of event measuing
> >>> a kind of thing
> >>>
> >>> D11 Digital Measurement Event
> >>> L17 measured thing of type E55
> >>>
> >>> http://www.cidoc-crm.org/crmdig/sites/default/files/CRMdig_v3.2.1.pdf
> >>>  >
> >>>
> >>> So, anyhow, putting that all together, I note:
> >>>
> >>> people document their scientific machines and what they do
> >>> some of the properties pertain to the machine (it may measure only
> >>> these things)
> >>> there are several references to such a property already in crmsci
> >>> and dig but placed on the event.
> >>>
> >>> So I wonder, for discussion, is there an interest in an instrument
> >>> class (possibly beginning a bridge between sci and dig) which would
> >>> not just be a leaf node but have its own substantial properties. I
> >>> suggest a first one might be something like 'measures
> >>> property/variable of type'.
> >>>
> >>> This is not yet a proposal for such a thing, just an invitation to
> >>> discussion for those who are interested on the potential utility of
> >>> such an addition.
> >>>
> >>> Best,
> >>>
> >>> George
> >>>
> >>>
> >>> ___
> >>> Crm-sig mailing list
> >>> Crm-sig@ics.forth.gr
> >>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
> >>
> >>
> >> --
> >> --

Re: [Crm-sig] Argument for an Instrument Class (and its property)

[Martin Doerr via Crm-sig]

Dear All,

Just to give you a picture of the diversity and complexity we discuss.

Probably the high-end in complexity is a DNA - taxonomic distance 
measurement, a procedure, even though straightforward and deterministic, 
as I understand, with an great number of steps, a series of instruments 
subsequently used and possible errors in each one.


Interesting also a LIPS / Raman analysis of painting colorants, which 
uses multiple instruments until the final result,  not reliably 
quantitative and including assumptions about a limited set of possible 
colorants that might be wrong.


As the most simple ones we may have yard sticks, but the most exotic in 
simplicity I can think of are pyrometric cones. They are used worldwide 
to monitor ceramic firings in industrial kilns, pottery kilns, for a 
one-time measurement of the maximum temperature reached by firing a 
kiln. They are calibrated to one temperature only, but normally 
destroyed by the measurement.


What is "one instrument", and are pyrometric cones and yardsticks 
instruments? What about body parts (ells, feet)


Best

Martin

On 9/6/2021 1:59 PM, Athanasios Velios via Crm-sig wrote:
I think this would be a useful discussion and class. It has also been 
proposed within the PARCOURS model although perhaps a tighter proposal 
can be made.


Thanasis

P.S. The example for P103 could do with updating...

On 01/09/2021 20:47, Martin Doerr via Crm-sig wrote:

Hi George,

I think this is a good idea, of course, we should first look at a 
more specific property, since "instruments" can be very 
heterogeneous, or we concentrate on measurement devices in a narrower 
sense.


Best,

Martin

On 8/25/2021 12:53 PM, George Bruseker via Crm-sig wrote:

Dear all,

I am working on a conservation science modelling project in which 
the users document also their machinery. Something that comes up is 
that they want to document the kind of property or variable that is 
measured by the machine. This is a property of the machine, what it 
can do (dunamis).


We of course already have p103 was intended for
http://www.cidoc-crm.org/Property/P103-was-intended-for/version-7.1.1 



I already make use of this for the purpose of documenting the 
general kind of method the machine can be used for.


But when you run the machine, it tests for certain variables and 
produces a resulting output which is a digital record of a signal 
carrying that variable.


This reminds me of some elements from CRMSci and from CRMdig

CRMSci has observations that look for property types:

S4 Observation
O9 observed property type E55

http://www.cidoc-crm.org/crmsci/sites/default/files/CRMsci%20v.1.3.pdf 



We also have in CRMdig both a class for instruments (digital ones)

D8 Digital Device

and we again have a notion of an observation kind of event measuing 
a kind of thing


D11 Digital Measurement Event
L17 measured thing of type E55

http://www.cidoc-crm.org/crmdig/sites/default/files/CRMdig_v3.2.1.pdf 



So, anyhow, putting that all together, I note:

people document their scientific machines and what they do
some of the properties pertain to the machine (it may measure only 
these things)
there are several references to such a property already in crmsci 
and dig but placed on the event.


So I wonder, for discussion, is there an interest in an instrument 
class (possibly beginning a bridge between sci and dig) which would 
not just be a leaf node but have its own substantial properties. I 
suggest a first one might be something like 'measures 
property/variable of type'.


This is not yet a proposal for such a thing, just an invitation to 
discussion for those who are interested on the potential utility of 
such an addition.


Best,

George


___
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



--

 Dr. Martin Doerr
  
 Honorary Head of the

 Center for Cultural Informatics
 
 Information Systems Laboratory

 Institute of Computer

Re: [Crm-sig] RDFS, XML and more

[Pavlos Fafalios via Crm-sig]

Dear Robert,

Thank you for your comments and feedback. Some answers inline:

On Wed, Sep 1, 2021 at 4:40 PM Robert Sanderson  wrote:

>
> Miel, all,
>
> 4 issues below:
>
> (1) There is a 7.1.1 compatible JSON-LD context at:
> https://linked.art/ns/v1/linked-art.json
> The description for how the JSON keys are derived from the ontology is:
> https://linked.art/api/1.0/json-ld/#context-design
> Comments welcome and happy to contribute it to the SIG, and make only a
> secondary linked art context for the profile specific features!
>

Please see my reply to Miel.


>
> (2) A second request from me ... it would be great to have owl:inverseOf
> between each of the property pairs in the ontology.
>
> e.g.
>
>xml:lang="en">identifies xml:lang="de">bezeichnetείναι 
> αναγνωριστικό xml:lang="fr">identifie xml:lang="pt">identifica xml:lang="ru">идентифицирует xml:lang="zh">标识 />* rdf:resource="P1_is_identified_by" />*  
>
>
>
Our intention was to provide a 'pure' RDFS implementation, since one of our
next steps is to provide a rich OWL implementation (and also automate its
production, as we do for RDFS).
Nevertheless, including this OWL property does not seem to cause any
problem and allows for at least some basic reasoning. Not sure if it is
better to provide it as a separate module/file, or just enrich the existing
file.


> And (3) a minor typo:
>
>   
> Linguistic Appellation
> 
> 
>   
>
> It was agreed that this was going to be E33_E41 to keep the numbers in
> order, and to coincidentally correspond to the two parts of the label (E33
> -> linguistic, E41-> appellation)
> Great if this could be fixed.
>

Thanks for spotting, we will fix it.


>
> And (4) a concern. I don't think that it is good practice to make
> assertions about other ontologies' predicates:
> Line 1176 asserts:
>
>   http://www.w3.org/2000/01/rdf-schema#label";>
> 
>   
>
> So this means that all of the objects of instances of rdfs:label are, due
> to the range of P1_is_identified_by, suddenly instances of E41_Appellation.
> A system that does even basic inferencing will produce very different
> results, by assigning E41_Appellation as another class for all of the
> literals which are the object of rdfs:label.
>
> This doesn't affect me, because while inferencing is a good idea in
> practice in some domains with very tightly controlled data and precisely
> applied ontologies and vocabularies, I have yet to see any benefit at all
> from it in ours.
>
> Might I suggest as a compromise instead having this assertion published,
> but in a different rdfs file? That would make it more noticeable to people
> who might otherwise have no clue why their system was misbehaving all of a
> sudden, and also make it easier for it to be omitted from processing if it
> was not useful in practice. Then we're still making the assertion in an
> official, public capacity, but we're also giving agency to our users as to
> whether they want to use it.
>

The reason for making this assertion is the fact that rdfs:label has been
widely used for providing names/appellations (without making use of "P1 is
identified by"). However, all these labels are (semantically) appellations
of the corresponding resources. So, using this subproperty declaration, a
system can use P1 together with an inference rule for retrieving both names
expressed using rdfs:label and instances of E41 (or appellations that are
in URL/URI form --a more complex case).

It's not very clear to me why some systems will start misbehaving. Could
you please provide an example of such misbehaviour and the platform of
reference? The only case I can imagine (but I might be wrong!) is when a
system uses P1 together with an inference rule for retrieving appellations,
but for some reason it does not want to get back values of rdfs:label,
although these are appellations (but again here SPARQL offers constructs
that can be used to distinguish between the different types of
appellations).

Thanks again!

Best regards,
Pavlos


>
> Thanks for your hard work on this!
>
> Rob
>
>
>
>
>
>
>
> On Wed, Sep 1, 2021 at 8:44 AM Miel Vander Sande via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> Thanks to all involved for this contribution. This is indeed an important
>> step towards adoption.
>>
>> I was wondering: is a SHACL profile and a JSON-LD context being
>> considered?
>>
>> Op wo 1 sep. 2021 om 10:19 schreef Pavlos Fafalios via Crm-sig <
>> crm-sig@ics.forth.gr>:
>>
>>> Dear all,
>>>
>>> The "Resources" page of the CIDOC-CRM website (
>>> http://www.cidoc-crm.org/versions-of-the-cidoc-crm) has been recently
>>> updated to include:
>>>
>>> - An *RDFS implementation* (*not yet approved by SIG*) of the last
>>> official version of CIDOC-CRM (7.1.1). The link points to a gitlab web page
>>> which also includes the policies adopted for generating the RDFS file.
>>> - An *XML file* for each version of CIDOC-CRM, including the classes
>>> and properties of the cor

Re: [Crm-sig] RDFS, XML and more

[Pavlos Fafalios via Crm-sig]

Dear Alexander,

Yes. As far as I know, the plan is to review and update all models based on
7.1.1 (by the corresponding working groups).
Then, we plan to also provide an RDFS implementation for these models
(whose generation has been automated to a great extent; we just need to
check if specific policies need to be considered).

Best regards,
Pavlos

On Thu, Sep 2, 2021 at 6:32 PM Alexander Huber via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Pavlos,
>
> This is fabulous news, thanks to all involved!  One question: is there a
> timeline for bringing the compatible models in line with this release,
> particularly LRMoo, CRMinf, and CRMdig?
>
> Thanks!
>
> Alexander.
> --
> Huber Digital
> https://www.hubers.org.uk/
> ___
> Crm-sig mailing list
> Crm-sig@ics.forth.gr
> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>


-- 
Dr. Pavlos Fafalios
Postdoctoral research fellow
Project ReKnow  (MSCA Individual Fellowship)

Centre for Cultural Informatics / Information Systems Laboratory
Institute of Computer Science (ICS)
Foundation for Research and Technology (FORTH)
   and
Visiting Lecturer
Department of Management Science & Technology (MST),
Hellenic Mediterranean University (HMU)

Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
Email: fafal...@ics.forth.gr
Tel: +30-2810-391619
Web: http://users.ics.forth.gr/~fafalios/
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] RDFS, XML and more

[Pavlos Fafalios via Crm-sig]

Dear Miel,

Thank you for your comments.

Having a JSON-LD serialization seems useful, given the increasing adoption
of this encoding format. We can start considering its implementation once
the RDFS is approved by CRM SIG.

About SHACL: do you mean using SHACL for schema validation, or for defining
constraints/requirements over crm-compliant RDF graphs? I guess the latter.
This is interesting as well, but it also requires careful design and
thinking/discussions on what types of constraints to consider and define.

Best regards,
Pavlos

On Wed, Sep 1, 2021 at 3:37 PM Miel Vander Sande 
wrote:

> Thanks to all involved for this contribution. This is indeed an important
> step towards adoption.
>
> I was wondering: is a SHACL profile and a JSON-LD context being considered?
>
> Op wo 1 sep. 2021 om 10:19 schreef Pavlos Fafalios via Crm-sig <
> crm-sig@ics.forth.gr>:
>
>> Dear all,
>>
>> The "Resources" page of the CIDOC-CRM website (
>> http://www.cidoc-crm.org/versions-of-the-cidoc-crm) has been recently
>> updated to include:
>>
>> - An *RDFS implementation* (*not yet approved by SIG*) of the last
>> official version of CIDOC-CRM (7.1.1). The link points to a gitlab web page
>> which also includes the policies adopted for generating the RDFS file.
>> - An *XML file* for each version of CIDOC-CRM, including the classes and
>> properties of the corresponding version.
>> - An *HTML page* for each version of CIDOC-CRM, containing declarations
>> for all classes and properties (facilitating navigation to the classes and
>> properties of each version).
>> - An HTML page for each version of CIDOC-CRM, containing *translations *and
>> *versioning *information of all classes and properties.
>>
>> We (at FORTH) believe that the above will facilitate the adoption of
>> CIDOC-CRM.
>>
>> We will start gathering comments about errors, improvements, etc., so
>> please do not hesitate to provide your critical feedback.
>>
>> All the above will be presented and discussed during the next CIDOC-CRM
>> meeting.
>>
>> Best regards,
>> Pavlos
>>
>> --
>> Dr. Pavlos Fafalios
>> Postdoctoral research fellow
>> Project ReKnow  (MSCA Individual Fellowship
>> )
>>
>> Centre for Cultural Informatics / Information Systems Laboratory
>> Institute of Computer Science (ICS)
>> Foundation for Research and Technology (FORTH)
>>and
>> Visiting Lecturer
>> Department of Management Science & Technology (MST),
>> Hellenic Mediterranean University (HMU)
>>
>> Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
>> Email: fafal...@ics.forth.gr
>> Tel: +30-2810-391619
>> Web: http://users.ics.forth.gr/~fafalios/
>>
>> ___
>> Crm-sig mailing list
>> Crm-sig@ics.forth.gr
>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>>
>

-- 
Dr. Pavlos Fafalios
Postdoctoral research fellow
Project ReKnow  (MSCA Individual Fellowship)

Centre for Cultural Informatics / Information Systems Laboratory
Institute of Computer Science (ICS)
Foundation for Research and Technology (FORTH)
   and
Visiting Lecturer
Department of Management Science & Technology (MST),
Hellenic Mediterranean University (HMU)

Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
Email: fafal...@ics.forth.gr
Tel: +30-2810-391619
Web: http://users.ics.forth.gr/~fafalios/
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig