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 ?
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]
<mailto:[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] <mailto:[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] <mailto:[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
<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
<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
<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]
<mailto:[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]
<mailto:[email protected]>>:
Dear all,
The "Resources" page of the CIDOC-CRM website
(http://www.cidoc-crm.org/versions-of-the-cidoc-crm
<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]
<mailto:[email protected]>
Tel: +30-2810-391619
Web: http://users.ics.forth.gr/~fafalios/
<http://users.ics.forth.gr/~fafalios/>
_______________________________________________
Crm-sig mailing list
[email protected] <mailto:[email protected]>
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
<http://lists.ics.forth.gr/mailman/listinfo/crm-sig>
_______________________________________________
Crm-sig mailing list
[email protected] <mailto:[email protected]>
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
<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] <mailto:[email protected]>
Tel: +30-2810-391619
Web: http://users.ics.forth.gr/~fafalios/
<http://users.ics.forth.gr/~fafalios/>
_______________________________________________
Crm-sig mailing list
[email protected] <mailto:[email protected]>
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
<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
_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
