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! (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. <rdf:Property rdf:about="P1i_identifies"> <rdfs:label xml:lang="en">identifies</rdfs:label> <rdfs:label xml:lang="de">bezeichnet</rdfs:label> <rdfs:label xml:lang="el">είναι αναγνωριστικό</rdfs:label> <rdfs:label xml:lang="fr">identifie</rdfs:label> <rdfs:label xml:lang="pt">identifica</rdfs:label> <rdfs:label xml:lang="ru">идентифицирует</rdfs:label> <rdfs:label xml:lang="zh">标识</rdfs:label> <rdfs:domain rdf:resource="E41_Appellation" /> <rdfs:range rdf:resource="E1_CRM_Entity" />* <owl:inverseOf rdf:resource="P1_is_identified_by" />* </rdf:Property> And (3) a minor typo: <rdfs:Class rdf:about="E41_E33_Linguistic_Appellation"> <rdfs:label xml:lang="en">Linguistic Appellation</rdfs:label> <rdfs:subClassOf rdf:resource="E41_Appellation" /> <rdfs:subClassOf rdf:resource="E33_Linguistic_Object" /> </rdfs:Class> 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. And (4) a concern. I don't think that it is good practice to make assertions about other ontologies' predicates: Line 1176 asserts: <rdf:Property rdf:about="http://www.w3.org/2000/01/rdf-schema#label";> <rdfs:subPropertyOf rdf:resource="P1_is_identified_by" /> </rdf:Property> 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. Thanks for your hard work on this! Rob On Wed, Sep 1, 2021 at 8:44 AM Miel Vander Sande via Crm-sig < [email protected]> 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 < > [email protected]>: > >> 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 <https://reknow.ics.forth.gr/> (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: [email protected] >> Tel: +30-2810-391619 >> Web: http://users.ics.forth.gr/~fafalios/ >> >> _______________________________________________ >> Crm-sig mailing list >> [email protected] >> http://lists.ics.forth.gr/mailman/listinfo/crm-sig >> > _______________________________________________ > Crm-sig mailing list > [email protected] > http://lists.ics.forth.gr/mailman/listinfo/crm-sig > -- Rob Sanderson Director for Cultural Heritage Metadata Yale University
_______________________________________________ Crm-sig mailing list [email protected] http://lists.ics.forth.gr/mailman/listinfo/crm-sig
