Re: [Crm-sig] error in RDFS for 7.1.1 for the class that is a subclass of E41 and E33

[Mark Fichtner via Crm-sig]

Dear all,

while I must agree with Rob that the three classes he proposed for deletion
are not a particular best pratice in ontology building from a semantic
point of view, I don't feel good with the direction the CRM is going
currently. At our museum we are following the CRM because it is the only
"really standardized" standard for our domain. It is expressive enough for
a full top level ontology while also covering the domain of cultural
heritage. We are not interested in yet another standard that maps metadata
in a very common way - we have enough of these and if we would want to use
dublin core we would do so. The full potential of the CRM is what binds us
to using it.

Concepts like "Title" are really important for our domain - it is one of
the most important metadata fields for documentation in our museum. With
the abolishment of properties and classes in CRM Base that were used a lot
in the past the SIG and the CRM takes a turn away from the museum side of
documentation towards being a very general ontology. While I know
development may always hurt a little bit, this does not feel right in any
way anymore.

I am asking myself: Is this really what the CIDOC CRM should do? Is it
possible for the CIDOC CRM to survive in comparison to standards that are
more widely spread while abolishing it's own user base? Do we really want a
domain ontology - extending CRM Base called "CRM Museum Documentation
Ontology" because we throw out everything that is museum related out of CRM
Base? At least I might have my long loved E84 Information Carrier back
there... :D

No offense intended - just my two cents and the perspective of the GNM
Nürnberg on the current CRM development...

Best,

Mark



Am Di., 8. Nov. 2022 um 21:51 Uhr schrieb Robert Sanderson via Crm-sig <
crm-sig@ics.forth.gr>:

>
> Thank you for the clarification, Martin!
>
> I have proposed the justifications for deleting three further classes that
> do not, I believe, fulfil the criteria of being classes in CRM Base.
>
> And indeed, let us judge these objectively and by the given criteria,
> rather than subjective and personal preferences. If we come across a class
> that we simply cannot delete without irreparable damage to the ontology, at
> *that point* let us reconsider the criteria as being incomplete.
>
> Thanks again,
>
> Rob
>
>
>
> On Tue, Nov 8, 2022 at 2:24 PM Martin Doerr via Crm-sig <
> crm-sig@ics.forth.gr> wrote:
>
>> Dear All,
>>
>> I just want to remind that we have a principle explicitly in the
>> introduction of the CRM not to add classes without distinct properties of
>> their own which is sufficiently relevant. By this, we purged a lot of very
>> useful classes from the CRM, because it is "base".
>>
>> I prefer not to hear again "if we don't like a class". I kindly ask
>> members to delete such terms from our vocabulary.
>>
>> Any argument in favour of a class in CRMbase which is nothing more
>> semantics than multiple IsA, must be measured by this principle, and not by
>> likes.
>>
>> If the principle is to be abandoned again, please make an issue. If the
>> principle is unclear, please make an issue.
>>
>> Any issue for adding more custom classes to RDFS, to be discussed.
>>
>> Best,
>>
>> Martin
>>
>> On 11/8/2022 5:46 PM, Pavlos Fafalios via Crm-sig wrote:
>>
>> Dear George and Robert,
>>
>> Your comments are well taken and understood. I do not take a position
>> against or for the addition of this class (I'm not yet sure of either
>> decision), nor I support that "rules" must be always respected. I just
>> tried to find a good reason for not having already introduced such a class
>> (and thus facilitate the discussion).
>>
>> Best,
>> Pavos
>>
>> On Tue, Nov 8, 2022 at 5:00 PM Robert Sanderson 
>> wrote:
>>
>>>
>>> I agree with George that this should be added.
>>>
>>> There are plenty of cases of classes without additional properties that
>>> serve only to join two parent classes. For example E22_Human-Made_Object,
>>> E25_Human-Made_Feature, and E34_Inscription. There are also remaining leaf
>>> nodes with no properties with only one parent class, such as E27_Site.
>>> Further, there are classes that have a property, but which is semantically
>>> indistinguishable from its super property. If the requirement is a
>>> property, then I propose
>>>
>>> Pxx_is_named_by (names)
>>> Domain: E1
>>> Range: Exx_Name (previously E33_E41)
>>> Sub Property Of: P1_is_identified_by
>>> Super Property Of:  P102 has title
>>>
>>> This property describes the naming of any entity by a name in a human
>>> language.
>>>
>>> And the
>>> Exx_Name
>>> Super Class: E33, E41
>>> Super Class Of: E35 Title
>>>
>>>
>>> The discussion last time devolved to "Well we use those so we don't want
>>> to get rid of them so we're not going to even though they don't have
>>> properties". But here's the thing ... *everything* has a Name (by which I
>>> mean an E33_E41_Linguistic_Appellation). And it's easy to demonstrate that
>>> E33_E41 is very well used.
>>>
>>>

Re: [Crm-sig] ISSUE 588 Implementing the .1 Properties of Base and Extensions in RDF

[Mark Fichtner via Crm-sig]

Dear all,

nice work, thanks! I think for RDF this is a valid representation, although
I am not very happy to add properties that are not in the cidoc crm
directly and that are not part of the language itself (like in this
case crm:P03_reifies). As a user/reader of the rdf it is simply hard to
understand what is part of the cidoc crm itself and what comes due to
"workarounds". Even in as a new ontology/file/addon it mixes cidoc crm and
non-cidoc crm things.

Also we have a reification concept (E13 Attribute Assignment), I am not
sure if we need even more of these.

I'm looking forward to the discussion!

Best,

Mark Fichtner

Germanisches Nationalmuseum

Am Mo., 12. Sept. 2022 um 14:22 Uhr schrieb Pavlos Fafalios via Crm-sig <
crm-sig@ics.forth.gr>:

> Dear all,
>
> Please find my homework for issue 588
> <https://cidoc-crm.org/Issue/ID-588-common-policy-method-for-implementing-the-.1-properties-of-base-and-extensions-in-rdf>
> in the below link (as well as in the issues' folder):
>
>
> https://docs.google.com/document/d/1oQRkmMUgyOeDsn3ZbPuQ__VtbigS9DVsHjmOtvx16uo/edit?usp=sharing
>
> Apologies for the delay! Feel free to add your comments or send your
> feedback!
>
> Best regards,
> Pavlos
>
>
> --
> Pavlos Fafalios
>
> Postdoctoral researcher (Marie Curie IF - Project ReKnow
> <https://reknow.ics.forth.gr/>)
> Centre for Cultural Informatics & Information Systems Laboratory
> Institute of Computer Science - FORTH
>
> Visiting Lecturer
> Department of Management Science & Technology
> Hellenic Mediterranean University
>
> Web: http://users.ics.forth.gr/~fafalios/
> Email: fafal...@ics.forth.gr
> Address: N. Plastira 100, Vassilika Vouton, 70013 Heraklion, Greece
> Tel: +30-2810-391619
>
> ___
> 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] New Erlangen CRM Version

[Mark Fichtner via Crm-sig]

Dear all,

thanks to Juliane Hamisch and Robert Nasarek I can announce a new version
of the Erlangen CRM (http://erlangen-crm.org/current-version, or on Github:
https://github.com/erlangen-crm/ecrm/blob/master/ecrm_211015.owl) based on
CIDOC CRM 7.1.1. We hope it will be a good base for a new CIDOC CRM ISO
Standard version as soon as the standardisation process is done. So any
feedback or contribution is welcome!

Best,

Mark
___
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 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] 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] New Erlangen OWL Version based on CIDOC CRM 6.2.9

[Mark Fichtner]

Not a manual one - you can make a diff between the Versions, if you want
to. All is on github:
https://github.com/erlangen-crm/ecrm

The content diff is in the crm of course :)

Best,

Mark

Marco Neumann  schrieb am Fr. 17. Juli 2020 um
15:47:

> Great Mark, is there a diff for changes or a change log?
>
> Best,Marco
>
> On Fri, Jul 17, 2020 at 2:43 PM Mark Fichtner 
> wrote:
>
>> Dear all,
>>
>> just finished the work on the new erlangen crm 200717 (
>> http://erlangen-crm.org/current-version) based on CIDOC CRM 6.2.9.
>>
>> Keep up the good work!
>>
>> Mark
>>
> ___
>> Crm-sig mailing list
>> Crm-sig@ics.forth.gr
>> http://lists.ics.forth.gr/mailman/listinfo/crm-sig
>
>
>>
>
> --
>
>
> ---
> Marco Neumann
> KONA
>
>
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig

[Crm-sig] New Erlangen OWL Version based on CIDOC CRM 6.2.9

[Mark Fichtner]

Dear all,

just finished the work on the new erlangen crm 200717 (
http://erlangen-crm.org/current-version) based on CIDOC CRM 6.2.9.

Keep up the good work!

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

Re: [Crm-sig] HW of ISSUE 357

[Mark Fichtner]

Dear all, Dear CEO,

Am Mo., 21. Okt. 2019 um 18:57 Uhr schrieb Christian-Emil Smith Ore <
c.e.s@iln.uio.no>:

> Dear all
>
> Here is the homework of ISSUE .
>
> Best,
>
> Christian-Emil
>
>
>
> The number of shortcuts has changed due to  deprecation of properties and
> a few new. The eventual change of E4 isa E92 to a property etc, will result
> in 4 new shortcuts marked as red text below. One existing shortcut has to
> be redefined, marked in read as well.
>
>
> In the long discussion of formalizing shortcuts in FOL, the two terms
>  strong shortcut and weak shortcut were introduce. A shortcut is weak when
> the existence of a long path implies an instance of the shortcut. In a
> graph the instantiation of  the long path should automatically introduce a
> triple for the shortcut. It should be noted that there can be more than one
> instantiation of a long path.
>
>
> A strong shortcut is a weak shortcut where the instantiation of the
> shortcut implies the existence of a long path.  As long as the long path
> need not to be unique, I think this is ok in FOL. However, this may
> contradict the open world view ad also the timelessness of some properties
> like P1, P2. To make things simple I have defined all shortcuts as weak
> shortcuts. That is, the long path implies the short.
>
>
> I have removed the “declaration” of class for intermediate nodes in the
> path where these are implied from the propertydefintion:
>

I don't think that this is a good thing to do as due to open world
assumption it will be misleading. It will be "smarter" for interns like us,
but more difficult for externals. Furthermore the scope note becomes less
complete by that.

>
> P105(x,y) ⊂ [E30(z) ˄ P104(x,z) ˄ P75(y,z)] becomes P105(x,y) ⊂ [P104(x,z)
> ˄ P75(y,z)]
>
> since P104(x,z) ⊃ E30(z) and also P75(y,z) ⊃ E30(z).
>
>
> The CRMbase document has no FOL description of the shortcuts. In 2015 when
> we started this work the intension was to add a line to those properties
> that are shortcuts, e.g.
>
>
> In First Order Logic:
>
>P105(x,y) ⊃ E72(x)
>
>P105(x,y) ⊃ E39(y)
>
> Shortcut: P105(x,y) ⊂ [ P104(x,z) ˄ P75(y,z)]
>
>
>
> To add this is pure editorial work, the sig should just decide yes or no.
>
>
>
>
>
>
>
>
> 1.   P1 is identified by (identifies), is a shortcut for the path from
> ‘E1 CRM Entity’ through ‘P140i was attributed by’, ‘E15 Identifier
> Assignment’, ‘P37 assigned’,‘E42 Identifier’, ‘P139 has alternative form’
> to ‘E41 Appellation’.
>
> P1(x,y) ⊂ [P140(z.x) ˄ P141(z,y)]
>
The naming is difficult and I don't understand your solution in any
way.. I usually would propose:
P1(x,a) ⊂ [P140(y,x) ˄ E15(y) ^ P37(y,z) ^ E42(z) ^ P139(z,a) ^ E41(a) ]

or easier using i for inverse:
P1(x,a) ⊂ [P140i(x,y) ˄ E15(y) ^ P37(y,z) ^ E42(z) ^ P139(z,a) ^ E41(a)]

or following your logic:
P1(x,a) ⊂ [P140(y,x) ^ P37(y,z)  ^ P139(z,a) ]


>
>
>
> 2.   P2: Type assignment events allow a more detailed path from ‘E1
> CRM Entity’ through ‘P41i was classified by’, ‘E17 Type Assignment’, ‘P42
> assigned’, to ‘E55 Type’ for assigning types to objects compared to the
> shortcut offered by P2 has type (is type of).
>
> P2(x,y) ⊂ )[ P41(z.x) ˄ P42(z,y)]
>
  P2(x,y) ⊂ [ P41(z,x) ˄ P42(z,y)] is ok - I would prefer P2(x,y) ⊂ [
P41(z,x) ˄ P42(z,y) ^ E17(z)] or P2(x,y) ⊂ [ P41i(x,z) ˄ P42(z,y) ^ E17(z)]


>
>
>
> 3.   [P7 took place at (witnessed)] It is a shortcut of the more fully
> developed path from E4 Period through P161 has spatial projection, E53
> Place, P89 falls within  to E53 Place. E4 Period is a subclass of E92
> Spacetime Volume. By the definition of P161 has spatial projection an
> instance of E4 Period takes place on all its spatial projections, that is,
> instances of E53 Place. Something happening at a given place can also be
> considered to happen at a larger place containing the first. For example,
> the assault on the Bastille July 14th 1789 took place in the area covered
> by Paris in 1789 but also in the area covered by France in 1789.
>
> P7(x,y) ⊂ [E4(x)  ˄ P161(x,z) ˄ P89(z,y)]
>
> P7(x,y) ⊂ [Pyyy(x,w) ˄ P161(w,z) ˄ P89(z,y)]
>

I really have a bad feeling with the scope note here. What is described
here is not the typical shortcut but an implication or a rule. I guess
these should be handled differently. Furthermore this is probably not
precise enough as the part with "E53 Place, P89 falls within, E53 Place" is
transitive - I don't know how to express that in an easy way here and I
don't think that there is an easy way to do that with FOL at all.
Nethertheless:

P7(x,y) ⊂ [E4(x) ˄ P161(x,z) ˄ P89(z,y)] is ok - I would prefer P7(x,y) ⊂
[E4(x) ˄ P161(x,z) ˄ E53(z) ^ P89(z,y) ^ E53(y)]


>
>
>
>
> 4.   P8 took place on or within (witnessed) is a shortcut of the more
> fully developed path from ‘E4 Period’ through ‘P7 took place at’, ‘E53
> Place’, ‘P156i is occupied by’, to ‘E18 Physical Thing’
>
> P8(x,y) ⊂ [P7(x,z) ˄ P156

Re: [Crm-sig] NEW ISSUE: symbolic content

[Mark Fichtner]

Dear all,

thanks for the proposal Martin. I think it should have some relation to P3
- probably it is a subproperty? Especially the examples really make it look
like a subproperty to P3.

Best,

Mark

2018-09-19 22:09 GMT+02:00 Martin Doerr :

> Here my scope note:
>
> Pxxx has symbolic content
>
> Domain: E90 Symbolic Object
> <#m_-5231204896452987831__E2_Temporal_Entity>
>
> Range:E62 String
>
> Quantification:many to many (0,n:0,n) ??
>
>
>
> Scope note: This property associates  an instance of E90 Symbolic
> Object with a complete, identifying representation of its content in the
> form of an instance of E62 String. This property only applies to instances
> of E90 Symbolic Object that can be represented completely in this form. The
> representation may be more specific than the symbolic level defining the
> identity condition of the represented. This depends on the type of the
> symbolic object represented. For instance, if a name has type "Modern Greek
> character sequence", it may be represented in a loss-free Latin
> transcription, meaning however the sequence of Greek letters. As another
> example, if the represented object has type "English words sequence",
> American English or British English spelling variants may be chosen to
> represent the English word "colour" without defining a different symbolic
> object. If a name has type "European traditional name", no particular
> string may define its content.
>
>
>
> Examples:
>
>
> * The materials description (E33) of the painting (E22)  _*has symbolic
> content*_ “Oil, French Watercolors on Paper, Graphite and Ink on Canvas,
> with an Oak frame.”
>
> * The title (E35) of Einstein’s 1915 text (E73) _*has symbolic content*_
> “Relativity, the Special and the General Theory“
>
> * The story of Little Red Riding Hood (E33) _*has symbolic content*_
> “Once upon a time there lived in a certain village …”
> * The inscription (E34) on Rijksmuseum object SK-A-1601 (E22) _*has
> symbolic content*_ “B”
>
>
>
>
> On 9/17/2018 10:38 PM, Robert Sanderson wrote:
>
>
>
> Examples I have a lot of!
>
>
>
>
>
> How about …
>
>
>
> * The materials description (E33) of the painting (E22)  _*has symbolic
> content*_ “Oil, French Watercolors on Paper, Graphite and Ink on Canvas,
> with an Oak frame.”
>
> * The title (E35) of Einstein’s 1915 text (E73) _*has symbolic content*_
> “Relativity, the Special and the General Theory“
>
> * The story of Little Red Riding Hood (E33) _*has symbolic content*_
> “Once upon a time there lived in a certain village …”
>
> * The inscription (E34) on Rijksmuseum object SK-A-1601 (E22) _*has
> symbolic content*_ “B”
>
>
>
> Rob
>
>
>
>
>
> *From: *Crm-sig 
>  on behalf of Richard Light
>  
> *Date: *Monday, September 17, 2018 at 12:09 PM
> *To: *"crm-sig@ics.forth.gr"  
> 
> *Subject: *Re: [Crm-sig] NEW ISSUE: symbolic content
>
>
>
> Rob,
>
> Absolutely.  So now we need to draft the text to describe this property,
> in suitably generalized terms, for the CRM, and then update our RDF
> documentation to say exactly how it is to be used in that context.  Perhaps
> we should start with some examples?
>
> Richard
>
> On 17/09/2018 19:49, Robert Sanderson wrote:
>
>
>
> Thank you, Martin! I think this is exactly what we need ☺
>
>
>
> Rob
>
>
>
> *From: *Crm-sig 
>  on behalf of Martin Doerr
>  
> *Date: *Friday, September 14, 2018 at 10:23 AM
> *To: *"crm-sig@ics.forth.gr"  
> 
> *Subject: *[Crm-sig] NEW ISSUE: symbolic content
>
>
>
> Dear All,
>
> I propose a new property of Symbolic Object : "has symbolic content :
> String" , in RDFS subproperty of rdfs:value.
>
> The "level of symbolic specificity" by which the String is interpreted
> should conform to the type of the Symbolic Object.
>
> Best,
>
> Martin
>
> On 9/14/2018 7:54 PM, Richard Light wrote:
>
>
>
> On 13/09/2018 20:57, Martin Doerr wrote:
>
> Dear Richard,
>
>
>
>
>
> What we need, to my opinion, is a property of Symbolic Object we may call
> it "has symbolic content" or "has symbolic content inline" or anything
> better, which defines that the symbolic content *is identical to* the
> Literal, *abstracted *to the "level of symbolic specificity" that the
> Literal implies and that conforms to the identity condition of the Symbolic
> Object, i.e., characters of a certain script, or whatever. That would make
> the meaning of the "value" unambiguous.
>
> Again, I'm in complete agreement with this line of thought.  One decision
> we should make is whether this property forms part of the generic CRM
> framework, or if it is to be an implementation-specific property which only
> appears in our RDF implementation of the CRM.  My instinct is for it to go
> into the CRM proper: the treatment of Symbolic Object and its subclasses
> would I think be made clearer by the addition of this property.
>
> For CRM proper!
>
> OK: perhaps we should start a new issue to address this?
>
>
>
>
> --
>
> --

Re: [Crm-sig] Issue: Solution for Dualism of E41 Appellation and rdfs:label

[Mark Fichtner]

Dear all,

the main question for me is: Is the use of rdf:label in this case really
the intended way by the CIDOC CRM? In fact P1 currently has a valid range
and E41 is a valid class and not a primitive datatype. Why should we
substitute this?

I agree with Martin that we should integrate old data that has a different
model and therefore the proposal and the work is very nice to see. However
I think we should have exactly one best practice. At the GNM we typically
have regular instances of E41, which in my eyes follows the CIDOC CRM
better, so I would love to see this in the best practice.

Best,

Mark Fichtner

2018-09-04 21:29 GMT+02:00 Robert Sanderson :

> Hi Detlev,
>
>
>
> Apologies, I meant that the pattern makes it more complicated to
> understand, as opposed to it being ambiguous in the data (which would be
> much worse!). More difficult for a human rather than for the machine :)
>
>
>
> For example, in JSON-LD, it would result in
>
>
>
> {
>
>   “P1_is_identified_by”: [
>
>   “uri-as-string”,
>
>   {
>
>  “@id”: “uri-as-identifier”
>
>   }
>
>   ]
>
> }
>
>
>
> Which then makes developers cross, as there are mixed data types in the
> array, and the current specification doesn’t allow the string to be
> expressed in an object with only @value as a key.
>
>
>
> Currently that would be the simpler compaction of:
>
>
>
> {
>
>   “P1_is_identified_by: [
>
>   “uri-as-identifier”
>
>   ]
>
> }
>
>
>
> Because P1 can only ever have a resource as its object.
>
>
>
> Or (if you don’t care for the singleton array), the simplest possible form:
>
>
>
> {
>
>   “P1_is_identified_by”: “uri-as-identifier”
>
> }
>
>
>
> Rob
>
>
>
> *From: *Crm-sig  on behalf of Detlev Balzer
> 
> *Date: *Tuesday, September 4, 2018 at 12:11 PM
> *To: *"crm-sig@ics.forth.gr" 
> *Subject: *Re: [Crm-sig] Issue: Solution for Dualism of E41 Appellation
> and rdfs:label
>
>
>
> Am 04.09.2018 um 19:19 schrieb Robert Sanderson:
>
> In particular, it makes it difficult in several serializations to
> distinguish between the string “http://example.museum.org/data/1” and the
> resource that has the URI http://example.museum.org/data/1 as its
> identifier.
>
>
>
> Which ones do you mean? All the serializations I've seen make clear
> syntactic distinctions between literals and URIs.
>
>
>
> While I agree that "punning" is bad practice, I don't see why it should
> confuse RDF software tools.
>
>
>
> Detlev
>
>
>
>
>
> Am 04.09.2018 um 19:19 schrieb Robert Sanderson:
>
>
>
> Dear all,
>
>
>
> Please no!  This is called “punning” (when the same property can be have
> both literals and resources as its range) and is widely recognized as a bad
> practice in RDF.
>
>
>
> In particular, it makes it difficult in several serializations to
> distinguish between the string “http://example.museum.org/data/1” and the
> resource that has the URI http://example.museum.org/data/1 as its
> identifier.
>
>
>
> Rob
>
>
>
>
>
> *From: *Crm-sig  on behalf of Martin Doerr <
> mar...@ics.forth.gr>
>
> *Date: *Saturday, September 1, 2018 at 7:41 AM
>
> *To: *crm-sig 
>
> *Subject: *[Crm-sig] Issue: Solution for Dualism of E41 Appellation and
> rdfs:label
>
>
>
> Dear All,
>
> Obviously, there are two ways in RDF to express what the CRM regards as an
> Appellation: Either using a URI, instance of E41, and then another property
> specifying in whatever way the symbolic content (I am not concerned with
> this here), *OR *using rdfs:label, which has exactly the meaning of some
> forms of Appellation that can be expressed exhaustively as literal.
>
> Interesting enough, there seems to be no existing validation method, that
> would exclude any instance of xsd Datatype to be used as range of
> rdfs:label.
>
> We have made therefor the following tests with Virtuoso, if P1 can have
> two ranges, Literal and E41, and if SPARQL gives the expected answers, it
> does:
>
> *1.**  **Dualism of Appellations*
>
> The purpose of this is to provide an *RDF based technical solution* for
> representing and querying a property which can be at the same time Data and
> Object type regardless of the fact that it violates the respective
> constraints or rules.
>
> Practically we can have three options of representing appellations. By
> taking the example of Alexander the Great with supposed URI:
> http://example.com/person/alexander_the_great we can do the following:
>
> 1)  Use the “P1 is identified b

Re: [Crm-sig] Participation to forthcoming meeting

[Mark Fichtner]

Dear Chryssoula,

Siegfried and I will be there.

Best regards,

Mark

2015-09-30 19:40 GMT+02:00 Christian-Emil Smith Ore :

> Dear Chryssoula,
> I will arrive Monday evening and leave after lunch Friday.
>
> Regards,
> Christian-Emil
>
> >-Original Message-
> >From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr] On Behalf Of
> >Chryssoula Bekiari
> >Sent: Monday, September 28, 2015 7:56 PM
> >To: crm-sig
> >Subject: [Crm-sig] Participation to forthcoming meeting
> >
> >Dear All
> >
> >I would like to ask you about your participation to the forthcoming
> meeting
> >in Crete.
> >The provisional agenda of the meeting has been published on the site
> >http://www.cidoc-crm.org/special_interest_meetings.html
> >
> >best regards
> >
> >Chryssoula
> >
> >PS.
> >You may find also the new versions of CIDOC CRM, CRMarchaeo, CRMgeo in
> >the following links http://www.cidoc-crm.org/official_release_cidoc.html
> >http://www.cidoc-crm.org/technical_papers.html
> >
> >--
> >--
> >Chryssoula Bekiari
> >Research and Development Engineer
> >
> >Center for Cultural Informatics / Information Systems Laboratory
> Institute of
> >Computer Science Foundation for Research and Technology - Hellas (FORTH)
> >
> >N. Plastira 100, Vassilika Vouton, GR-700 13 Heraklion, Crete, Greece
> >Phone: +30 2810 391631, Fax: +30 2810 391638, Skype: xrysmp
> >E-mail: beki...@ics.forth.gr
> >
> >Web-site:
> >http://www.ics.forth.gr/isl/people/people_individual.jsp?Person_ID=13
>
> >-
> >
> >
> >___
> >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] ISSUE: Shortcut semantics

[Mark Fichtner]

Dear Martin,

some time ago we also had a discussion about this topic on the Erlangen CRM
mailing list. Perhaps some of this work is already done, have a look here:
https://groups.google.com/forum/#!msg/erlangen-crm/ojF1l8EhoPc/2bzmgIbW3sQJ
- List of Shortcuts
https://groups.google.com/forum/?hl=en#!topic/erlangen-crm/tJ4JDk8tcQI -
Discussion about Shortcuts

Best regards,

Mark Fichtner



2014-08-31 14:49 GMT+02:00 martin :

>  Dear All,
>
> I work together with Carlo Meghini on a formalization of
> CIDOC CRM in first order logic, in order to have an encoding
> neutral, compact form for OWL implementations and other reasoning
> services. We'll present this work for discussion in the next
> CRM-SIG meeting.
>
> One issue that occurred is the meaning of shortcuts.
> In all cases, the extended path implies the shortcut,
> but only in a few cases the shortcut implies a particular
> path so that the existence of the intermediates can be
> inferred. (such as "rights held by").
>
> Who would volunteer to scan the latest version for that?
>
> All the best,
>
> Martin
>
> --
>
> --
>  Dr. Martin Doerr  |  Vox:+30(2810)391625|
>  Research Director |  Fax:+30(2810)391638|
>|  Email: mar...@ics.forth.gr |
>  |
>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   |
>  |
>  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] Document for approval

[Mark Fichtner]

Dear Martin,

I would be happy to contribute and provide constructive alternative texts.
However I also think just like Vladimir that on google docs it would be
easier to contribute than by discussing .pdf-files on the mailing list.
Criticising people who at least try to contribute is not very positive
either in my humble opinion.

Best regards,

Mark Fichtner


2014-08-14 21:21 GMT+02:00 martin :

> Dear All,
>
> After some relatively global criticism we have heard by some of you about
> the CRM Primer http://www.cidoc-crm.org/docs/CRMPrimer_v1.1.pdf,
> I'd like to point out that I regard this document as particularly well
> written,
> and to express my particular thanks to the authors!
>
> We also have indications that the document is much better accepted by real
> audience,
> than appears following your critisism.
>
> On that occasion, I would like to remind you, that CRM-SIG is a group of
> volunteers.
> All texts are created without payment, out of personal engagement and
> interest.
> We have discussed for more than 10 years the need of such an introduction,
> but no one
> has provided one.
>
> Lack of positive engagement is an issue for this group.
> Normally I would expect comments to be constructive, providing explicit
> alternative texts
> rather than telling colleagues who invested a considerable effort to do
> another homework.
>
> Probably my fault how I have introduced this work.
>
> If I am mistaken, I gladly accept your criticism!
>
> Best,
>
> Martin
>
>
>
>
> --
>
> --
>  Dr. Martin Doerr  |  Vox:+30(2810)391625|
>  Research Director |  Fax:+30(2810)391638|
>|  Email: mar...@ics.forth.gr |
>  |
>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   |
>  |
>  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] Document for approval

[Mark Fichtner]

Dear all,

it seems that you feel yourself personally offended, Barry. I don't think
Georg did mean this, Martin asked for feedback and he got some - personally
I think that is the best that can happen for science.

I think many points which Georg mentioned are valid. I don't want to repeat
them, I just also got the same impression that Georg got from the document.
I want to explain my point of view with PDF pages 13-14 (labeled 11-12 in
the document itself - I would suggest to make this consistent, too.):
This paragraph is labelled "9.2 Example of using Entities with Properties
with RDF" - so it is an example and examples should be easy to understand
because they illustrate important parts. However the image on top of page
14 (or 12 due to the label on the page) is absolutely not the semantically
equivalent in rdf to the image on the bottom of page 11 which illustrates
the CRM view. A possible correction is illustrated in the attachment.

If you look carefully at the current image, then you can see that it is
semantically equivalent to: "http://collection.amuseum.org/id/object/1234 being
a E42_Identifier and a E22_Man-made_Object at the same time and refering to
itself via P1_is_identified_by." However the crm-example states "There is a
Man Made Object which is called The Hoa Hakananai and it is identified by
an identifier which is an accession number". This is not what the primer
tries to describe above, it is not easy to understand, not logical correct,
not the rdf representation of the crm view above and therefore just a bad
example in a primer. Thank you for pointing that out, Georg, I didn't see
it so clear this way before.


The following part is labelled "9.3 URI Schema" and not "9.3 Examples for a
consistent URI Schema". Furthermore it states that "Resources (like an
object or an identifier) are assigned a URI providing a logical structure
when
implementing RDF. URI schemata are created to reflect the resources in
question.". This means that the URI has to provide "a logical structure" -
what are the requirements for this "logical structure" in detail? Is a UUID
a valid logical structure? Why are all examples URLs?

Perhaps this helps to get this a little bit more constructive.

Best regards,

Mark Fichtner


2014-08-12 17:04 GMT+02:00 Barry Norton :

>
>
>
>
> -Original Message-
> From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr] On Behalf Of Georg
> Hohmann
> Sent: 12 August 2014 15:33
> To: crm-sig@ics.forth.gr
> Subject: Re: [Crm-sig] Document for approval
>
>
>
> >> Georg, your comment about the URI scheme into which a given material
>
> >> fits seems motivated not by the Primer but rather by the British
>
> >> Museum data
>
> >
>
> > Since the the URI scheme of the BM is given as a linked data example in
> the primer, my comments are about the texts
>
> > and the figures in the primer and the purpose they serve.
>
>
>
> The mention of /material in the example URIs is just an arbitrary example
> of object-specific resources and I've agreed with Dominic that this can be
> changed or dropped if it confuses.
>
>
>
> Again, the Primer does not cover that there are two sources of resources
> for materials in the BM data; the confusion only arises when you look at a
> larger example than the Primer and don't examine resources in terms of
> their relationships but instead focus on the URIs.
>
>
>
>
>
> >> That being said, one should not attempt to 'read' URIs, that's a basic
>
> >> principle of REST as much as Linked Data;
>
> >
>
> > Yes, for sure. So why should a primer include an example that creates
> the appearance that URIs
>
> > should have a structure that makes them "more readable" for humans?
>
>
>
> If that's the impression then it should be clarified. As it standard for
> REST over HTTP the URIs should be crafted to be *maintainable for the
> service provider* (which is the intention of this exemplar scheme), *not
> transparent to the user*.
>
>
>
>
>
> > it will be hard to find any other resource that mints URIs the way that
> is given in the primer, because -
>
> > as you said yourself - it is not common practice.
>
>
>
> Well, I don’t think I’ve said that, but equally it’s not intended to
> be(come) common practice. The URI scheme of the Primer illustrates that one
> can establish a consistent hierarchical URI scheme to publish data
> according to the CRM, not that one must follow the particular scheme used
> in examples (which seems to offend you because it’s a projection from the
> BM one, but it’s only an example of what one could use).
>
>
>
>