Re: [Crm-sig] RDFS, XML and more

[Robert Sanderson via Crm-sig]

Thanks Martin :)

As Francesco asked and Thomas answered, I would also recommend a property
chain axiom that says:

If: x rdfs:label y
then: x P1_is_identified_by z ; z a E41_Appellation ,
P190_has_symbolic_content y .

I quickly defer to those who do OWL more often than I, but I think it's as
easy as:

rdfs:label owl:propertyChainAxiom (crm:P1_is_identified_by,
crm:P190_has_symbolic_content) .

Rob


On Thu, Sep 9, 2021 at 4:18 PM Martin Doerr  wrote:

> Sorry, I just forgot:
>
> Of course we can provide guidelines and S/W how to query all names etc.
> We can hardly forbid CRM users to put appellations into rdfs:label.
>
> So, how do this problem solved in OWL? Those of you opposing to the
> superproperty hack, how do you solve the query question?
>
> Best,
>
> Martin
>
> On 9/9/2021 11:12 PM, Martin Doerr wrote:
> > Dear Robert, Mark,
> >
> > Of course this is not elegant schema design. Unease is accepted, but
> > what are the alternatives??
> >
> > On 9/9/2021 10:30 PM, Robert Sanderson wrote:
> >>
> >>
> >>
> >> As expected, it entails the nonsense that the literal "fish"@en is an
> >> E1, E41, E90, etc. which is garbage caused by this pollution in the
> >> ontology, as literals cannot be the subject of triples.
> > This is, in my eyes, not nonsense, but simply reality. The literal
> > "fish" is used as a name. Hence it is ontologically an E41. Following
> > the definition of E90, "fish"@en is also symbolic object, regardless
> > whether one distinguishes data objects and literals. Note, that the
> > definitions of the CRM are ontological, not syntactic in the first place.
> >
> > This is a classical problem of data integration, and why formal
> > ontologies were invented. Literature in the 1980ties discussed that
> > classes can be hidden in boolean values, strings, or be explicit
> > tables. There is an arbitrary decision of applications to name things
> > via labels, or via classes in RDF/OWL. SKOS exclusively names things
> > via labels.
> >
> > So, if one makes a knowledge base that commits to the CRM, I would
> > like to have a query that returns all names in the whole world I can
> > reach, regardless what encoding variant and KR paradigm is used.
> > Otherwise, SKOS names will not be appellations.
> >
> > Alternatively, we close our eyes, and hard code in data entry and
> > query that "fish" is used as Appellation, but just don't write it down.
> >
> > @en actually is equivalent to "has language" etc. With these hidden
> > properties RDFS itself violates the separation of Literals and data
> > objects.  It opens up a whole world of user-defined data objects
> > within Literals, with no logical connection to the data objects. This
> > is nothing than a bad later patch to a problem not initially
> > anticipated. How are these compatible with OWL reasoners?
> >
> > There is no elegant solution to providing an ontology that describes a
> > reality based on FOL to fitting it exactly with Schema languages.
> >
> > At least, this is how I perceive this problem, having seen enough
> > knowledge representation languages and information integration
> > literature from the eighties and implementations from the nineties on.
> >
> > For me, the question is completely practical: We have a CRM compatible
> > KB, a real platform. What is the simplest form that I get all names in
> > the KB back?  I have not seen a whole "RDF" world that my statement
> > label IsA P1 would turn upside down. Do you have one?
> >
> > Best,
> >
> > Martin
> >>
> >> Hope that helps explain my unease!
> >>
> >> Rob
> >>
> >
>
>
> --
> 
>   Dr. Martin Doerr
>
>   Honorary Head of the
>   Center for Cultural Informatics
>
>   Information Systems Laboratory
>   Institute of Computer Science
>   Foundation for Research and Technology - Hellas (FORTH)
>
>   N.Plastira 100, Vassilika Vouton,
>   GR70013 Heraklion,Crete,Greece
>
>   Vox:+30(2810)391625
>   Email: mar...@ics.forth.gr
>   Web-site: http://www.ics.forth.gr/isl
>
>

-- 
Rob Sanderson
Director for Cultural Heritage Metadata
Yale University
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Linked Places mapping

[Øyvind Eide via Crm-sig]

For work on gazetteers I would suggest to bring in Humphrey Southall.

https://www.port.ac.uk/about-us/structure-and-governance/our-people/our-staff/humphrey-southall

He has been working on them for decades and argued they organise information in 
a way which is useful also in a digital world.

All the best,

Øyvind 

> Am 09.09.2021 um 19:35 schrieb Christian-Emil Smith Ore via Crm-sig 
> :
> 
> Still the information in a gazetteers and in old land (mediaeval, early 
> modern) registries can be organized compliant with CRM. I assume that is what 
> is meant. This, in my opinion, an interesting task and could help a lot.
> Best,
> Christian-Emil
> 
> 
> From: Crm-sig  on behalf of Martin Doerr via 
> Crm-sig 
> Sent: 09 September 2021 18:50
> To: crm-sig@ics.forth.gr
> Subject: Re: [Crm-sig] Linked Places mapping
>  
> Dear Francesco, Richard,
> 
> I am a bit confused. Even though people wrongly call a gazetteer a "place 
> name ontology", it has nothing to do with ontology, because it is a 
> collection of particulars. A place is not a class. 
> 
> I understand that the mapping exercise is a data transformation from Pelagios 
> schema, rather than the data about places, to CRM (geo). That should be a 
> question of X3ML.
> 
> Is or includes ontome.net a schema mapping tool with data tansformation 
> instructions? 
> 
> All the best,
> 
> Martin
> 
> On 9/9/2021 5:41 PM, Francesco Beretta via Crm-sig wrote:
>> Dear Richard,
>> Notwithstanding a more authoritative response, we have developed the 
>> ontome.net application precisely for coping with this kind of issues – and 
>> providing in the end a RDF (XML-OWL) export of the mapping.
>> So, if you're interested, we can exchange on this.
>> Best wishes
>> Francesco
>> Le 09.09.21 à 12:46, Richard Light via Crm-sig a écrit :
>>> Hi,
>>> The Linked Pasts gazetteer group (part of Pelagios) yesterday expressed an 
>>> interest in mapping their Linked Places ontology to the CIDOC CRM. What is 
>>> the current state of the art for doing this sort of mapping?  The last time 
>>> I was involved in such an exercise, the result ended up in a 
>>> not-very-processible spreadsheet, but I have a feeling we can do better 
>>> than that these days.
>>> Thanks,
>>> Richard
>>> -- 
>>> Richard Light
>>> richardlight...@gmail.com 
>>> @richardofsussex
>>> 
>>> 
>>> ___
>>> 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 
>> 
> 
> 
> -- 
> 
>  Dr. Martin Doerr
>   
>  Honorary Head of the 
>   
>  Center for Cultural Informatics
>  
>  Information Systems Laboratory  
>  Institute of Computer Science 
>  Foundation for Research and Technology - Hellas (FORTH)   
>   
>  N.Plastira 100, Vassilika Vouton, 
>  GR70013 Heraklion,Crete,Greece 
>  
>  Vox:+30(2810)391625  
>  Email: mar...@ics.forth.gr   
>  Web-site: http://www.ics.forth.gr/isl 
> ___
> 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

Re: [Crm-sig] RDFS, XML and more

[Martin Doerr via Crm-sig]

Sorry, I just forgot:

Of course we can provide guidelines and S/W how to query all names etc. 
We can hardly forbid CRM users to put appellations into rdfs:label.


So, how do this problem solved in OWL? Those of you opposing to the 
superproperty hack, how do you solve the query question?


Best,

Martin

On 9/9/2021 11:12 PM, Martin Doerr wrote:

Dear Robert, Mark,

Of course this is not elegant schema design. Unease is accepted, but 
what are the alternatives??


On 9/9/2021 10:30 PM, Robert Sanderson wrote:




As expected, it entails the nonsense that the literal "fish"@en is an 
E1, E41, E90, etc. which is garbage caused by this pollution in the 
ontology, as literals cannot be the subject of triples.
This is, in my eyes, not nonsense, but simply reality. The literal 
"fish" is used as a name. Hence it is ontologically an E41. Following 
the definition of E90, "fish"@en is also symbolic object, regardless 
whether one distinguishes data objects and literals. Note, that the 
definitions of the CRM are ontological, not syntactic in the first place.


This is a classical problem of data integration, and why formal 
ontologies were invented. Literature in the 1980ties discussed that 
classes can be hidden in boolean values, strings, or be explicit 
tables. There is an arbitrary decision of applications to name things 
via labels, or via classes in RDF/OWL. SKOS exclusively names things 
via labels.


So, if one makes a knowledge base that commits to the CRM, I would 
like to have a query that returns all names in the whole world I can 
reach, regardless what encoding variant and KR paradigm is used. 
Otherwise, SKOS names will not be appellations.


Alternatively, we close our eyes, and hard code in data entry and 
query that "fish" is used as Appellation, but just don't write it down.


@en actually is equivalent to "has language" etc. With these hidden 
properties RDFS itself violates the separation of Literals and data 
objects.  It opens up a whole world of user-defined data objects 
within Literals, with no logical connection to the data objects. This 
is nothing than a bad later patch to a problem not initially 
anticipated. How are these compatible with OWL reasoners?


There is no elegant solution to providing an ontology that describes a 
reality based on FOL to fitting it exactly with Schema languages.


At least, this is how I perceive this problem, having seen enough 
knowledge representation languages and information integration 
literature from the eighties and implementations from the nineties on.


For me, the question is completely practical: We have a CRM compatible 
KB, a real platform. What is the simplest form that I get all names in 
the KB back?  I have not seen a whole "RDF" world that my statement 
label IsA P1 would turn upside down. Do you have one?


Best,

Martin


Hope that helps explain my unease!

Rob






--

 Dr. Martin Doerr
  
 Honorary Head of the

 Center for Cultural Informatics
 
 Information Systems Laboratory

 Institute of Computer Science
 Foundation for Research and Technology - Hellas (FORTH)
  
 N.Plastira 100, Vassilika Vouton,

 GR70013 Heraklion,Crete,Greece
 
 Vox:+30(2810)391625

 Email: mar...@ics.forth.gr
 Web-site: http://www.ics.forth.gr/isl

___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] RDFS, XML and more

[Martin Doerr via Crm-sig]

Dear Robert, Mark,

Of course this is not elegant schema design. Unease is accepted, but 
what are the alternatives??


On 9/9/2021 10:30 PM, Robert Sanderson wrote:




As expected, it entails the nonsense that the literal "fish"@en is an 
E1, E41, E90, etc. which is garbage caused by this pollution in the 
ontology, as literals cannot be the subject of triples.
This is, in my eyes, not nonsense, but simply reality. The literal 
"fish" is used as a name. Hence it is ontologically an E41. Following 
the definition of E90, "fish"@en is also symbolic object, regardless 
whether one distinguishes data objects and literals. Note, that the 
definitions of the CRM are ontological, not syntactic in the first place.


This is a classical problem of data integration, and why formal 
ontologies were invented. Literature in the 1980ties discussed that 
classes can be hidden in boolean values, strings, or be explicit tables. 
There is an arbitrary decision of applications to name things via 
labels, or via classes in RDF/OWL. SKOS exclusively names things via 
labels.


So, if one makes a knowledge base that commits to the CRM, I would like 
to have a query that returns all names in the whole world I can reach, 
regardless what encoding variant and KR paradigm is used. Otherwise, 
SKOS names will not be appellations.


Alternatively, we close our eyes, and hard code in data entry and query 
that "fish" is used as Appellation, but just don't write it down.


@en actually is equivalent to "has language" etc. With these hidden 
properties RDFS itself violates the separation of Literals and data 
objects.  It opens up a whole world of user-defined data objects within 
Literals, with no logical connection to the data objects. This is 
nothing than a bad later patch to a problem not initially anticipated. 
How are these compatible with OWL reasoners?


There is no elegant solution to providing an ontology that describes a 
reality based on FOL to fitting it exactly with Schema languages.


At least, this is how I perceive this problem, having seen enough 
knowledge representation languages and information integration 
literature from the eighties and implementations from the nineties on.


For me, the question is completely practical: We have a CRM compatible 
KB, a real platform. What is the simplest form that I get all names in 
the KB back?  I have not seen a whole "RDF" world that my statement 
label IsA P1 would turn upside down. Do you have one?


Best,

Martin


Hope that helps explain my unease!

Rob



--

 Dr. Martin Doerr
  
 Honorary Head of the

 Center for Cultural Informatics
 
 Information Systems Laboratory

 Institute of Computer Science
 Foundation for Research and Technology - Hellas (FORTH)
  
 N.Plastira 100, Vassilika Vouton,

 GR70013 Heraklion,Crete,Greece
 
 Vox:+30(2810)391625

 Email: mar...@ics.forth.gr
 Web-site: http://www.ics.forth.gr/isl

___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] RDFS, XML and more

[Robert Sanderson via Crm-sig]

Here, my understanding of the entailments from both an RDFS perspective
(not invalid entailments, just makes it impossible to use) and OWL
(actually invalid).

RDFS 1.1 says the following:

If a property P is a subproperty of property P', then all pairs of
resources which are related by P are also related by P'. The term
super-property is often used as the inverse of subproperty. If a property
P' is a super-property of a property P, then all pairs of resources which
are related by P are also related by P'.

See: https://www.w3.org/TR/rdf-schema/#ch_properties

So, the assertion is that rdfs:label (P) is a sub property of
P1_is_identified_by (P'), therefore all resources which are related by
rdfs:label are also related by P1_is_identified_by.

Thus, if there is an assertion  rdfs:label "fish"^^xsd:string .
Then it is a valid inference that  P1_is_identified_by
"fish"^^xsd:string .

Now let's look at rdfs:range.  RDFS 1.1 says:

rdfs:range is an instance of rdf:Property
 that is used to state that *the
values of a property are instances of one or more classes.*

(emphasis added)

RDFS asserts:

The rdfs:range  of rdfs:label
is rdfs:Literal .

CRM asserts at line 1174 of the RDFS:

P1_is_identified_by rdfs:range E41_Appellation


Thus, if  rdfs:label "fish", then "fish" rdf:type rdfs:Literal,
crm:E41_Appellation .

Which as Martin says is not impossible, because E41_Appellation is not
declared as disjoint with rdfs:Literal ... it's just utterly meaningless
and very annoying to anyone who has to deal with it, because
crm:E41_Appellation is not a subclass of rdfs:Literal, and every practical
syntax explicitly distinguishes between literals and URI references. E.g.
there is a *syntactic* difference between the URI "http://example.com/1";
and the string "http://example.com/1"; -- the former can be the subject of
triples, and the latter (like every literal) cannot.

So, by asserting that a predicate that has a declared range of a datatype
class is the sub property of a predicate that as a declared range of a
non-Datatype class, this entails that the object is both a datatype and a
resource, and *this cannot be serialized.*


In OWL, rdfs:label would be a DataProperty, and P1_is_identified_by would
be an ObjectProperty. DataProperty values MUST respect the lexical space of
the datatype, and this is where the problem happens, because the URI that
identifies the E41_Appellation is NOT in the datatype lexical space.
Further, a DataProperty and ObjectProperty *are* explicitly disjoint. In
5.8.1:

   - No IRI *I* is declared in *Ax* as being of more than one type of
   property; that is, no *I* is declared in *Ax* to be both object and
   data, object and annotation, or data and annotation property.

See: https://www.w3.org/TR/owl2-syntax/#Typing_Constraints_of_OWL_2_DL

As a demonstration, I attach a minimal schema derived from the current RDFS.

Then, using rdflib in python, using only RDFS entailment:

from rdflib import ConjunctiveGraph

from owlrl import RDFSClosure


g = ConjunctiveGraph()

g.parse("Downloads/minimal_schema.rdfs.xml", format="xml")

rdfs_sems = RDFSClosure.RDFS_Semantics(g, axioms=True, daxioms=True,
rdfs=True)

rdfs_sems.closure()

out = rdfs_sems.graph.serialize(format="ttl")

print(out.decode('utf-8'))

 ...

"fish"@en a crm:E1_CRM_Entity,

crm:E41_Appellation,

crm:E90_Symbolic_Object,

rdfs:Literal,

rdfs:Resource .

As expected, it entails the nonsense that the literal "fish"@en is an E1,
E41, E90, etc. which is garbage caused by this pollution in the ontology,
as literals cannot be the subject of triples.

Hope that helps explain my unease!

Rob

On Thu, Sep 9, 2021 at 12:48 PM Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr> wrote:

> Dear Francesco,
>
> This is a complex issue, which has been discussed in length in 2018 and
> basically was spelled out in the implementation guidelines for RDFS by
> Richrad Light and me.
>
> All these questions you pose have been taken into account carefully. The
> text may need improvements, but I'd kindly ask all CRM-SIG members having
> respective questions to read it carefully and give us feedback.
>
> Let me explain just a bit here from the side of logic, which is tricky and
> not the usual reasoning we apply within the CRM:
>
> A superproperty is not equivalent to a subproperty. A superproperty is
> only implied by a subproperty.
>
>  Therefore: Once E41 Appellation has no necessary property, an instance of
> E41 Appellation without having a property of its own does not violate the
> range of the superproperty. Its just a poor case.
>
> (But it is completely true that rdfs:label is without properties. From the
> time of RDFS 1.1 on, which recommends the use of xsd values in literals,
> there are hidden properties in the label, such as the language tags.)
>
> This statement does also st

Re: [Crm-sig] RDFS, XML and more

[Mark Fichtner via Crm-sig]

Dear all,

I am speaking from OWL-point of view and agree with most of the other
writers.
Concerning the P1-issue:
- rdfs:label has rdfs:Literal as range
- P1 in OWL typically is an object property and not a datatype property. It
has E41 as a range and E41 is not in the E59 primitive value subtree. Its
subclasses are via multiple inheritance, but it does not hold for E41
itself.
- If you declare rdfs:label a subproperty of P1 you are changing in fact
the definition of rdfs:label and the definition of E41. This means you
simply change the data on nearly the whole world without even having a
glance at a single dataset. This is not only a worst-practice but would
lead to massive inconsistencies when it comes to reasoning with OWL. I
don't want to tell you what you should do in rdf - because rdf is more
flexible here. But it does not seem logical to me. Ontology alignment is a
difficult task.
I  understand that it might be helpful in some scenarios. But I think it
would confusing if the official CIDOC CRM RDF file would do ontology
integration that way. Furthermore RDF is just one implementation of CIDOC
CRM and typically when it comes to implementation only primitive datatypes
are replaced by the implementation - not object properties.

In the Erlangen CRM we use:
- owl:Class for the classes,
- we have some owl:Restrictions (74)
- owl:ObjectProperty for the object properties
- owl:DatatypeProperty for the datatypes
- owl:inverseOf for the inverses
If I didn't miss anything, thats all. See http://erlangen-crm.org/200717/

So the difference between OWL and RDF variant won't be big after adding
owl:inverse and if you start using owl in your ontology definition it is
pretty straight forward to use OWL completely anyway ;-)

We had a long discussion on shortcuts - I think the conclusion was we
hardly have shortcuts in CIDOC CRM that could be used as Property chains as
the implications are not strong enough. Martin probably can add some in
here.

Best,

Mark





Am Do., 9. Sept. 2021 um 18:55 Uhr schrieb Martin Doerr via Crm-sig <
crm-sig@ics.forth.gr>:

> Dear Francesco,
>
> This is a complex issue, which has been discussed in length in 2018 and
> basically was spelled out in the implementation guidelines for RDFS by
> Richrad Light and me.
>
> All these questions you pose have been taken into account carefully. The
> text may need improvements, but I'd kindly ask all CRM-SIG members having
> respective questions to read it carefully and give us feedback.
>
> Let me explain just a bit here from the side of logic, which is tricky and
> not the usual reasoning we apply within the CRM:
>
> A superproperty is not equivalent to a subproperty. A superproperty is
> only implied by a subproperty.
>
>  Therefore: Once E41 Appellation has no necessary property, an instance of
> E41 Appellation without having a property of its own does not violate the
> range of the superproperty. Its just a poor case.
>
> (But it is completely true that rdfs:label is without properties. From the
> time of RDFS 1.1 on, which recommends the use of xsd values in literals,
> there are hidden properties in the label, such as the language tags.)
>
> This statement does also strictly not hold: "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",
>
> because a) there is no axiom in CRM saying that Persistent Item and E62
> String are disjoint.
> b) There is no declaration in the RDFS implementation that
> rdf:Literal equals E62 Sting or
> E59 Primitive Value.
>
> Obviously, RDFS makes rich use of Literal, packing stuff like WKT
> geometric values  into them, which are used in geo-enabled triple stores.
>
> With the superproperty declaration, we say that whowever uses rdfs:label
> refers to a name (E41 Appellation). Unfortunately, RDFS does not allow us
> smarter things to do, but this gives the right answers to queries.
>
> All the best,
>
> Martin
>
> On 9/9/2021 6:46 PM, Francesco Beretta via Crm-sig wrote:
>
> There was unfortunately a copy-paste issue in my email.
> Le 09.09.21 à 17:35, Francesco Beretta a écrit :
>
> The P1 is identified by (identifies)
>  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?
>
>
> I mean:
>
> An instance of E41 can have this property:
> E41 Appellation — rdfs:label —> '[label]', right ?
>
> So the crm:P1 property cannot be equivalent to rdfs:label, right?
>
>
> With my apologies
>
> Francesco
>
>
>
> ___
> Crm-sig mailing 
> listCrm-sig@ics.forth.grhttp://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>
>
> --
> --

Re: [Crm-sig] Linked Places mapping

[Christian-Emil Smith Ore via Crm-sig]

Still the information in a gazetteers and in old land (mediaeval, early modern) 
registries can be organized compliant with CRM. I assume that is what is meant. 
This, in my opinion, an interesting task and could help a lot.

Best,

Christian-Emil



From: Crm-sig  on behalf of Martin Doerr via 
Crm-sig 
Sent: 09 September 2021 18:50
To: crm-sig@ics.forth.gr
Subject: Re: [Crm-sig] Linked Places mapping

Dear Francesco, Richard,

I am a bit confused. Even though people wrongly call a gazetteer a "place name 
ontology", it has nothing to do with ontology, because it is a collection of 
particulars. A place is not a class.

I understand that the mapping exercise is a data transformation from Pelagios 
schema, rather than the data about places, to CRM (geo). That should be a 
question of X3ML.

Is or includes ontome.net a schema mapping tool with data tansformation 
instructions?

All the best,

Martin

On 9/9/2021 5:41 PM, Francesco Beretta via Crm-sig wrote:

Dear Richard,

Notwithstanding a more authoritative response, we have developed the ontome.net 
application precisely for coping with this kind of issues – and providing in 
the end a RDF (XML-OWL) export of the mapping.

So, if you're interested, we can exchange on this.

Best wishes

Francesco

Le 09.09.21 à 12:46, Richard Light via Crm-sig a écrit :

Hi,

The Linked Pasts gazetteer group (part of Pelagios) yesterday expressed an 
interest in mapping their Linked Places ontology to the CIDOC CRM. What is the 
current state of the art for doing this sort of mapping?  The last time I was 
involved in such an exercise, the result ended up in a not-very-processible 
spreadsheet, but I have a feeling we can do better than that these days.

Thanks,

Richard

--

Richard Light
richardlight...@gmail.com
@richardofsussex



___
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




--

 Dr. Martin Doerr

 Honorary Head of the
 Center for Cultural Informatics

 Information Systems Laboratory
 Institute of Computer Science
 Foundation for Research and Technology - Hellas (FORTH)

 N.Plastira 100, Vassilika Vouton,
 GR70013 Heraklion,Crete,Greece

 Vox:+30(2810)391625
 Email: mar...@ics.forth.gr
 Web-site: http://www.ics.forth.gr/isl
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] Linked Places mapping

[Martin Doerr via Crm-sig]

Dear Francesco, Richard,

I am a bit confused. Even though people wrongly call a gazetteer a 
"place name ontology", it has nothing to do with ontology, because it is 
a collection of particulars. A place is not a class.


I understand that the mapping exercise is a data transformation from 
Pelagios schema, rather than the data about places, to CRM (geo). That 
should be a question of X3ML.


Is or includes ontome.net a schema mapping tool with data tansformation 
instructions?


All the best,

Martin

On 9/9/2021 5:41 PM, Francesco Beretta via Crm-sig wrote:


Dear Richard,

Notwithstanding a more authoritative response, we have developed the 
ontome.net application precisely for coping with this kind of issues – 
and providing in the end a RDF (XML-OWL) export of the mapping.


So, if you're interested, we can exchange on this.

Best wishes

Francesco

Le 09.09.21 à 12:46, Richard Light via Crm-sig a écrit :


Hi,

The Linked Pasts gazetteer group (part of Pelagios) yesterday 
expressed an interest in mapping their Linked Places ontology to the 
CIDOC CRM. What is the current state of the art for doing this sort 
of mapping?  The last time I was involved in such an exercise, the 
result ended up in a not-very-processible spreadsheet, but I have a 
feeling we can do better than that these days.


Thanks,

Richard

--

*Richard Light*
richardlight...@gmail.com
/@richardofsussex/

___
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



--

 Dr. Martin Doerr
  
 Honorary Head of the

 Center for Cultural Informatics
 
 Information Systems Laboratory

 Institute of Computer Science
 Foundation for Research and Technology - Hellas (FORTH)
  
 N.Plastira 100, Vassilika Vouton,

 GR70013 Heraklion,Crete,Greece
 
 Vox:+30(2810)391625

 Email: mar...@ics.forth.gr
 Web-site: http://www.ics.forth.gr/isl

___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] RDFS, XML and more

[Martin Doerr via Crm-sig]

Dear Francesco,

This is a complex issue, which has been discussed in length in 2018 and 
basically was spelled out in the implementation guidelines for RDFS by 
Richrad Light and me.


All these questions you pose have been taken into account carefully. The 
text may need improvements, but I'd kindly ask all CRM-SIG members 
having respective questions to read it carefully and give us feedback.


Let me explain just a bit here from the side of logic, which is tricky 
and not the usual reasoning we apply within the CRM:


A superproperty is not equivalent to a subproperty. A superproperty is 
only implied by a subproperty.


 Therefore: Once E41 Appellation has no necessary property, an instance 
of E41 Appellation without having a property of its own does not violate 
the range of the superproperty. Its just a poor case.


(But it is completely true that rdfs:label is without properties. From 
the time of RDFS 1.1 on, which recommends the use of xsd values in 
literals, there are hidden properties in the label, such as the language 
tags.)


This statement does also strictly not hold: "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",


because a) there is no axiom in CRM saying that Persistent Item and E62 
String are disjoint.
    b) There is no declaration in the RDFS implementation 
that rdf:Literal equals E62 Sting or

                        E59 Primitive Value.

Obviously, RDFS makes rich use of Literal, packing stuff like WKT 
geometric values  into them, which are used in geo-enabled triple stores.


With the superproperty declaration, we say that whowever uses rdfs:label 
refers to a name (E41 Appellation). Unfortunately, RDFS does not allow 
us smarter things to do, but this gives the right answers to queries.


All the best,

Martin

On 9/9/2021 6:46 PM, Francesco Beretta via Crm-sig wrote:


There was unfortunately a copy-paste issue in my email.

Le 09.09.21 à 17:35, Francesco Beretta a écrit :
The P1 is identified by (identifies) 
 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?



I mean:

An instance of E41 can have this property:
E41 Appellation — rdfs:label —> '[label]', right ?

So the crm:P1 property cannot be equivalent to rdfs:label, right?


With my apologies

Francesco



___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig



--

 Dr. Martin Doerr
  
 Honorary Head of the

 Center for Cultural Informatics
 
 Information Systems Laboratory

 Institute of Computer Science
 Foundation for Research and Technology - Hellas (FORTH)
  
 N.Plastira 100, Vassilika Vouton,

 GR70013 Heraklion,Crete,Greece
 
 Vox:+30(2810)391625

 Email: mar...@ics.forth.gr
 Web-site: http://www.ics.forth.gr/isl

___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] RDFS, XML and more

[Thomas Francart via Crm-sig]

Le jeu. 9 sept. 2021 à 17:51, Francesco Beretta via Crm-sig <
crm-sig@ics.forth.gr> 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)
>  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 
> 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 <
>> 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 
>>> 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.

   >>> xml:lang="en">identifies>>> xml:lang="de">bezeichnetείναι 
 αναγνωριστικό>>> xml:lang="fr">identifie>>> xml:lang="pt">identifica>>> xml:lang="ru">идентифицирует>>> xml:lang="zh">标识>>> rdf:resource="E41_Appellation" />>>> rdf:resource="E1_CRM_Entity" />*>>> rdf:resource="P1_is_identified_by" />*  



>>> 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:

   
 Linguistic Appellation
 
 
   

 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:

   http://www.w3.org/2000/01/rdf-schema#label";>
 
   

 So this means that all of the objects of instances of rdfs:label are,
 due to the range of P1_is_identified_by, sudd

Re: [Crm-sig] RDFS, XML and more

[Francesco Beretta via Crm-sig]

There was unfortunately a copy-paste issue in my email.

Le 09.09.21 à 17:35, Francesco Beretta a écrit :
The P1 is identified by (identifies) 
 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?



I mean:

An instance of E41 can have this property:
E41 Appellation — rdfs:label —> '[label]', right ?

So the crm:P1 property cannot be equivalent to rdfs:label, right?


With my apologies

Francesco


___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] RDFS, XML and more

[Francesco Beretta via Crm-sig]

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) 
 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 > 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 mailto: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
mailto: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.


identifies
bezeichnet
είναι αναγνωριστικό
identifie
identifica
идентифицирует
标识


**




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:

  
    Linguistic
Appellation
    
    
  

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:

  http://www.w3.org/2000/01/rdf-schema#label
">
    
  

So this means that all of the objects of instances o

Re: [Crm-sig] RDFS, XML and more

[Robert Sanderson via Crm-sig]

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  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 <
> 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 
>> 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.
>>>
>>>   >> xml:lang="en">identifies>> xml:lang="de">bezeichnetείναι 
>>> αναγνωριστικό>> xml:lang="fr">identifie>> xml:lang="pt">identifica>> xml:lang="ru">идентифицирует>> xml:lang="zh">标识>> rdf:resource="E41_Appellation" />>> rdf:resource="E1_CRM_Entity" />*>> rdf:resource="P1_is_identified_by" />*  
>>>
>>>
>>>
>> 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:
>>>
>>>   
>>> Linguistic Appellation
>>> 
>>> 
>>>   
>>>
>>> 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:
>>>
>>>   http://www.w3.org/2000/01/rdf-schema#label";>
>>> 
>>>   
>>>
>>> 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

Re: [Crm-sig] Linked Places mapping

[Francesco Beretta via Crm-sig]

Dear Richard,

Notwithstanding a more authoritative response, we have developed the 
ontome.net application precisely for coping with this kind of issues – 
and providing in the end a RDF (XML-OWL) export of the mapping.


So, if you're interested, we can exchange on this.

Best wishes

Francesco

Le 09.09.21 à 12:46, Richard Light via Crm-sig a écrit :


Hi,

The Linked Pasts gazetteer group (part of Pelagios) yesterday 
expressed an interest in mapping their Linked Places ontology to the 
CIDOC CRM. What is the current state of the art for doing this sort of 
mapping?  The last time I was involved in such an exercise, the result 
ended up in a not-very-processible spreadsheet, but I have a feeling 
we can do better than that these days.


Thanks,

Richard

--

*Richard Light*
richardlight...@gmail.com
/@richardofsussex/

___
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

[Crm-sig] Feature Collection

[Richard Light via Crm-sig]

Hi,

An examination of the very first concept in the Linked Places example
document - FeatureCollection - brings up a couple of general questions.

FeatureCollection is actually a part of the GeoJSON-LD vocabulary:
https://purl.org/geojson/vocab#FeatureCollection. The Linked Places
structure uses a merry assortment of borrowed concepts, from GeoJSON-LD,
FOAF, Dublin Core Terms, CIDOC CRM, ..., as well as defining its own
unique classes and properties.  Should my mapping address the full
structure that will be encountered in a Linked Places instance, or just
focus on the classes and properties which are defined uniquely for the
Linked Places Ontology?

My second question only needs answering if the answer to the first
question is "map everything". It is: how do you map a FeatureCollection
to the CRM? My understanding is that a FeatureCollection (at least in
the context of Linked Places) is a set of gazetteer entries, each of
which is a [description of a] SpaceTime Volume, i.e. a place with
temporal as well as spatial characteristics, names, etc. This collection
will have been put together by an individual or institution, and may
have rights associated with it, e.g. Open Data licence. The 'collection'
concepts in the CRM seem to be more focused on physical objects - I
suppose this FeatureCollection is a collection of Information Objects. 
Anyway, guidance from those who understand the CRM better than I do
would be appreciated.

Thanks,

Richard

-- 

*Richard Light*
richardlight...@gmail.com
/@richardofsussex/
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

[Crm-sig] Linked Places mapping

[Richard Light via Crm-sig]

Hi,

The Linked Pasts gazetteer group (part of Pelagios) yesterday expressed
an interest in mapping their Linked Places ontology to the CIDOC CRM.
What is the current state of the art for doing this sort of mapping? 
The last time I was involved in such an exercise, the result ended up in
a not-very-processible spreadsheet, but I have a feeling we can do
better than that these days.

Thanks,

Richard

-- 

*Richard Light*
richardlight...@gmail.com
/@richardofsussex/
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

Re: [Crm-sig] RDFS, XML and more

[Mark Fichtner via Crm-sig]

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 
> 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.
>>
>>   > xml:lang="en">identifies> xml:lang="de">bezeichnetείναι 
>> αναγνωριστικό> xml:lang="fr">identifie> xml:lang="pt">identifica> xml:lang="ru">идентифицирует> xml:lang="zh">标识> />*> rdf:resource="P1_is_identified_by" />*  
>>
>>
>>
> 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:
>>
>>   
>> Linguistic Appellation
>> 
>> 
>>   
>>
>> 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:
>>
>>   http://www.w3.org/2000/01/rdf-schema#label";>
>> 
>>   
>>
>> 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-s

Re: [Crm-sig] RDFS, XML and more

[Miel Vander Sande via Crm-sig]

Hi Robert,

That makes a lot of sense. If you were to only support a subset, you'd need
to accompagny it with a SHACL profile to indicate what shape the context
offers and to make sure that things don't go missing. Although in practice,
this might indeed create chaos rather than prevent it.

Best,

Miel

Op wo 8 sep. 2021 om 16:33 schreef Robert Sanderson :

>
> Dear Miel, all,
>
> On Wed, Sep 8, 2021 at 4:11 AM Miel Vander Sande via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> Op di 7 sep. 2021 om 09:38 schreef Pavlos Fafalios > >:
>>
>>> Having a JSON-LD serialization seems useful, given the increasing
>>> adoption of this encoding format. We can start considering its
>>> implementation once the RDFS is approved by CRM SIG.
>>>
>>
>> When done right, it can make complex models like CIDOC-CRM look a lot
>> less scary. I think the goal should not be a complete implementation of
>> CIDOC-CRM in a single context, but rather lead to an entry-level format
>> that can be expanded when necessary (json-ld allows you to do this). I'm
>> working on similar examples for PREMIS OWL.
>>
>
> I agree that a well crafted context can greatly improve usability of the
> ontology in modern software frameworks. This has been demonstrated very
> clearly in different domains since the standardization of JSON-LD 1.0 in
> 2014. I'm very happy to put as much effort as needed into this.
>
> However, I disagree about the goal. I feel that the SIG should provide a
> context that covers the same set of classes and predicates as in the RDFS.
> Composing multiple contexts together with no overlap would be extremely
> error-prone, with little way to detect those errors. For Linked Art, we
> started with two contexts ... the terms that we recommend from CRM in the
> profile, and the second was all the other terms. If you wanted to stick
> with just Linked Art, you imported one. If you wanted to use anything
> extra, you also imported the rest. And even that level of composition was
> highly frustrating for implementation, as you needed to know all of the
> terms used in the document in order to know whether you should use one or
> both. The easy solution was to always use both... defeating the purpose of
> splitting them.
>
> And the errors are difficult to detect because if a key in JSON-LD doesn't
> match an entry in an included context, it is silently ignored. So data
> would just disappear, and you had to go hunting through other people's
> documents (the contexts) to figure out why.
>
> By sticking to the same divisions as the RDFS files (e.g. one context for
> base, one for sci, one for geo, etc) it would be straightforward to manage
> from a publishing and consumption perspective at the ontology level, rather
> than at an application profile level.
>
> Rob
>
>
>
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig