Dear Pavlos, to my knowledge up to now the ecrm is the official OWL-implementation of the CIDOC CRM. Automation of the process seems to be a good idea, however in the last years we could provide many feedback while we were implementing cidoc crm (style/writing mistakes but also logical inconsistencies etc.). We are currently working on 7.1.1 but are not completely done yet. I think we should not mix owl and rdfs on the rdfs-level because that simply would make the rdfs-file obsolete. If we do that we could just use OWL because it is rdfs anyway.
Best Mark Am Di., 7. Sept. 2021 um 12:45 Uhr schrieb Pavlos Fafalios via Crm-sig < crm-sig@ics.forth.gr>: > Dear Robert, > > Thank you for your comments and feedback. Some answers inline: > > On Wed, Sep 1, 2021 at 4:40 PM Robert Sanderson <azarot...@gmail.com> > 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. >> >> <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> >> >> >> > 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: >> >> <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. >> > > 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: >> >> <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. >> > > 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 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: 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 >>>> >>> _______________________________________________ >>> 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 >> > > > -- > 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: 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 >
_______________________________________________ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
