Le jeu. 9 sept. 2021 à 17:51, Francesco Beretta via Crm-sig < [email protected]> a écrit :
> Dear Rob, all, > >> I'm curious also as to your thoughts on the rdfs:label / P1_identifies > issue? > > *À propos*: there is a question that has been on my mind for some time, > perhaps you can give me some insights. > > The P1 is identified by (identifies) > <https://ontome.net/property/1/namespace/1> property has E41 Appellation > as range. This class is subclass of Symbolic Object and Legal Object, > therefore a E77 Persistent Item and not a E62 String which is a E59 > Primitive Value. > > Therefore an instance of E41 Appellation — rdfs:label —> '[label]', right > ? So it crm:P1 cannot be equivalent to rdfs:label? > > > E1 Entity —rdfs:label—> rdfs:Literal would appear to be a shortcut of: > > E1 Entity —P1 is identified by—> E41 Appellation —rdfs:label—> '[label]' > > My question(s): > > 1. is this correct ? > 2. is there any way in OWL-DL or any other formal language to express the > notion of *shortcut* or path, with a start and an end class, and the > whole path inbetween ? > Indeed, this is OWL2 Property Chains : https://www.w3.org/TR/owl2-primer/#Property_Chains Thomas > > All the best > Francesco > > > > > > Le 09.09.21 à 16:46, Robert Sanderson via Crm-sig a écrit : > > > 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 > [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 > -- *Thomas Francart* -* SPARNA* Web de *données* | Architecture de l'*information* | Accès aux *connaissances* blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart tel : +33 (0)6.71.11.25.97, skype : francartthomas
_______________________________________________ Crm-sig mailing list [email protected] http://lists.ics.forth.gr/mailman/listinfo/crm-sig
