Hi Mark, Could you expand a little about "OWL is RDFS anyway"? The advantage of the current RDFS file is that it's easy to understand and process as XML without a full semantic stack. Once decorated with all of the owl details, it becomes more complex. Apart from owl:inverseOf and perhaps owl:ObjectProperty vs owl:DataProperty, is there anything else that would be added? Cardinality? Definition of shortcuts using axioms / rules?
I'm curious also as to your thoughts on the rdfs:label / P1_identifies issue? Many thanks! Rob On Thu, Sep 9, 2021 at 6:45 AM Mark Fichtner <[email protected]> wrote: > 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 < > [email protected]>: > >> Dear Robert, >> >> Thank you for your comments and feedback. Some answers inline: >> >> On Wed, Sep 1, 2021 at 4:40 PM Robert Sanderson <[email protected]> >> 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 < >>> [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 >>> >> >> >> -- >> 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 >> > -- Rob Sanderson Director for Cultural Heritage Metadata Yale University
_______________________________________________ Crm-sig mailing list [email protected] http://lists.ics.forth.gr/mailman/listinfo/crm-sig
