Re: [Crm-sig] P90 etc.

[Martin Doerr]

Dear Conal, All,

Your arguments well taken, we are still obliged in formal ontologies to 
have explicit semantics.
The use described by Robert, which fulfills a real need, appears here as 
"emergent semantics"
from the community, which deviates fromthe W3C definition. I argue that 
this can be formulated in quite
precise terms, similar to what Robert formulated, and then there will be 
not need to talk about a lack of semantics.

I'd like to settle that until the end of the next meeting.

Let us distinguish
a) "values" which are points or areas in abstract mathematical spaces, from
b) symbolic objects in the form of linear sequences of 
machine-encodeable symbols

c) things that cannot exist in a digital form.

For c) no "value" can be given. We have the classical Pierce's referent 
and referree situation.

For those guys we use names, in particular identifiers.

Only objects of the form b) can reside on machines, if they have the 
storage capacity. So, from all things
a formal ontology talks about, only for those we think of not only 
talking about them in machines, but also

putting them into machines.

Then the question is: Is the identity-providing content in a Literal in 
my database, in a digital file, or on a paper document?


For a) , only subsets in finite machine encodeable form can reside in 
machines. In that case, the encoded form is not the a) guy itself, but a 
guy of type b), which is interpreted not as a type b), but a type a) guy.


Names in particular, if their identity is given as DEFINED as a linear 
sequences of machine-encodeable symbols, are type b) guys, but that does 
not imply the type c) guy they may identify or not.


Therefore, if we distinguish the 3 cases, we can have perfect semantics, 
and then talk about how to encode the cases.
Nothing mysterious, but we must understand the above distinctions, which 
are not within a logical space, but between logical spaces and the world 
around.


I hope this makes things clearer!

Comments welcome.

Best,

Martin





On 3/14/2018 12:01 PM, Conal Tuohy wrote:



On 9 March 2018 at 04:39, Martin Doerr > wrote:




I recommend NOT to recommend rdf:value, because RDFS 1.1 defines:
"5.4.3 rdf:value rdf:value is an instance of rdf:Property
 that may be used
in describing structured values. rdf:value has no meaning on its
own. "

As CRM-SIG, we cannot recommend a property without meaning. We do
ontology here, so the must be a minimal ontological commitment.
Are there other opinions?


My opinion is that the real value of rdf:value is that it effectively 
negates one of the weaknesses in the expressiveness of RDF, with 
respect to the CRM.


In RDF, a literal value is a second-class citizen: it has no 
identifier, which makes it ineligible to appear as the subject of a 
triple, so it can't have properties of its own. It can't be woven into 
the "Web of Data". It can't effectively function as an "access point" 
(in the library science sense) without some additional context.


As Linked Data practitioners, we generally have literals like "Conal 
Tuohy" as our source data for e.g. Appellations (and it's worth noting 
that all of the formal examples of E41 Appellation are given as string 
literals), but it's highly undesirable to encode an E41 Appellation 
merely as a literal; such an encoding would make it impossible, either 
for us, or for third parties, to annotate that name with properties of 
its own ("A name of Irish origin ...").


So we must mint an identifier, either a local ("blank node") 
identifier -- or better still, an HTTP URI -- for that name (e.g. 
"_conal_tuohy"), so that we can then attach other properties to that 
identifier. We are left, finally, with the residual problem of how to 
associate the literal name value itself ("Conal Tuohy") with that 
identifier. This is where rdf:value plays a valuable role of 
effectively just equating the literal with identifier; it is described 
as having "no meaning on its own" precisely because it really plays 
only a syntactical role. This is why I think it would be a mistake to 
critique the use of rdf:value on the basis of it "lacking meaning of 
its own"; it would be equivalent to criticising a relational database 
for having an Appellation table with a column named "value".


Regards

"Conal Tuohy"




Taken the above definition in RDFS 1.1, I question both, the
precise use and the emerging good practice,
until better evidence:-).
Do you have better evidence?

It is up to crm-sig to decide, I present only my opinion here.

Best,

martin



On 3/8/2018 6:28 PM, Robert Sanderson wrote:


Martin,

Could you clarify why you have changed your mind about rdf:value?

> I recommend NOT to recommend rdf:value

In particular, in the last week you said:

“CRM-SIG normally works reactively: When a good community
practice emerges, 

Re: [Crm-sig] Properties of properties in RDF

[Martin Doerr]

Dear Conal,

Got it! Yes, subproperties of P01/P02 create an additional constraint, 
which obviously must hold. The reasoning that the PC class expands the 
equivalent property can only be modeled by an OWL rule.


For practical data entry, this should be hidden to the user by a tool, 
which understands exactly the PC semantics. Otherwise the user will be 
drowned under a hundred properties that only enforce obvious 
constraints. This is why we hesitated to publish it in such an expanded 
form.


I meant another issue: If the ".1" property declares a more specific 
type, the relationship between free typing of the base property versus 
creating subproperties of it should be better determined. Other 
properties of properties do not create such problem.


Imagine a fully developed hierarchy of role terms for the P14, with 
broader and narrower terms, such as "as designer" and "as architectural 
sketcher", and then someone declaring a subproperty of P14  called 
"designed by", but not "as architectural sketcher". Then, the 
equivalence of "designed by" and "as designer" could be declared by 
additional OWL rules, as well as that "as architectural sketcher", 
because of being narrower term of "as designer", also implies "designed by".


But, even without and not so badly, at least when declaring for PC14 "as 
designer", and when using "designed by", both declarations will result 
in a P14 link. So, P14 provides the common recall, but not the precision.


You may understand, why for many years I suggested people to create and 
share local subproperty vocabularies for the .1's, which saves a whole 
reasoning engine in the background, but, admittedly, is not as flexible.


But, the problem is analogous to the P2 has type.

All the best,

Martin

On 3/15/2018 1:51 PM, Conal Tuohy wrote:

Dear Martin

I'm not sure what you meant by "partially declared subproperties" 
there (the ambiguity of the term "subproperty" in this discussion 
doesn't help). I think I understood the rest of what you were saying, 
though.


To be clear, all I was saying was that I would prefer not to publish 
RDF that directly uses those generic RDF predicates P01_has_domain and 
P02_has_range, but instead to use a set of more specific predicates 
(which could be defined to be (RDFS) subproperties of those two 
predicates). So each distinct type of CRM property which had been 
reified as an RDFS class (e.g. PC14_carried_out_by) would have its own 
pair of RDF properties for linking to instances of its domain and range.


My rationale for that preference is that it would be more meaningful 
to users to make use of an RDF predicate called Pxxx_has_actor (with a 
domain of PC14_carried_out_by and a range of E39_Actor) and 
Pxxx_has_activity (with domain PC14_carried_out_by and range 
E7_Activity), rather than using generic predicates P01_has_domain and 
P02_has_range. Plus it would give us more type-safety. It would be a 
trivial extension to that existing RDFS to add those extra RDFS 
subproperties (about 60 of them, including the inverses).


Regards

Conal

On 15 March 2018 at 20:37, Martin Doerr > wrote:


Dear Conal,

There is no conflict with adding subproperties. Once we have
defined in FOL the logic of properties of properties, each PC
class implies its base property. Hence, logically, the subproperty
and any added ".1" will hold for the instances declared and imply
the same base property. If, at any time we wish to connect term
hierarchies of roles for the .1 properties with partially declared
subproperties, we need a straight-forward extension of the CRM.
Any subproperty, e.g., may refine domain and range.

All the best,

Martin


On 3/15/2018 6:28 AM, Conal Tuohy wrote:

Thanks Martin, for the link to
http://www.cidoc-crm.org/sites/default/files/CRMpc_v1.1_0.rdfs


This is actually very close to (and compatible with) the approach
I suggested in my earlier email, and I'm embarrassed to say I
wasn't aware of it at all.

I've managed to find some background material (though I had to
use Google to find it!)

http://www.cidoc-crm.org/Issue/ID-266-reified-association-vs-sub-event

is an archive of a relevant discussion.

http://www.cidoc-crm.org/sites/default/files/Roles.pdf
 presents
a few slides showing options for modelling properties of
properties, including the "Property Class" approach.

These slides include a nice illustration of the approach defined
in the RDFS:


http://www.cidoc-crm.org/sites/default/files/20160802PropertiesOfProperties.pptx



I think I'd be very happy with this "Property Class" approach,
  

Re: [Crm-sig] Properties of properties in RDF

[Conal Tuohy]

Dear Martin

I'm not sure what you meant by "partially declared subproperties" there (the
ambiguity of the term "subproperty" in this discussion doesn't help). I think
I understood the rest of what you were saying, though.

To be clear, all I was saying was that I would prefer not to publish RDF
that directly uses those generic RDF predicates P01_has_domain and
P02_has_range, but instead to use a set of more specific predicates (which
could be defined to be (RDFS) subproperties of those two predicates). So
each distinct type of CRM property which had been reified as an RDFS class
(e.g. PC14_carried_out_by) would have its own pair of RDF properties for
linking to instances of its domain and range.

My rationale for that preference is that it would be more meaningful to
users to make use of an RDF predicate called Pxxx_has_actor (with a domain
of PC14_carried_out_by and a range of E39_Actor) and Pxxx_has_activity
(with domain PC14_carried_out_by and range E7_Activity), rather than using
generic predicates P01_has_domain and P02_has_range. Plus it would give us
more type-safety. It would be a trivial extension to that existing RDFS to
add those extra RDFS subproperties (about 60 of them, including the
inverses).

Regards

Conal

On 15 March 2018 at 20:37, Martin Doerr  wrote:

> Dear Conal,
>
> There is no conflict with adding subproperties. Once we have defined in
> FOL the logic of properties of properties, each PC class implies its base
> property. Hence, logically, the subproperty and any added ".1" will hold
> for the instances declared and imply the same base property. If, at any
> time we wish to connect term hierarchies of roles for the .1 properties
> with partially declared subproperties, we need a straight-forward extension
> of the CRM. Any subproperty, e.g., may refine domain and range.
>
> All the best,
>
> Martin
>
>
> On 3/15/2018 6:28 AM, Conal Tuohy wrote:
>
> Thanks Martin, for the link to http://www.cidoc-crm.org/
> sites/default/files/CRMpc_v1.1_0.rdfs
>
> This is actually very close to (and compatible with) the approach I
> suggested in my earlier email, and I'm embarrassed to say I wasn't aware of
> it at all.
>
> I've managed to find some background material (though I had to use Google
> to find it!)
>
> http://www.cidoc-crm.org/Issue/ID-266-reified-association-vs-sub-event is
> an archive of a relevant discussion.
>
> http://www.cidoc-crm.org/sites/default/files/Roles.pdf presents a few
> slides showing options for modelling properties of properties, including
> the "Property Class" approach.
>
> These slides include a nice illustration of the approach defined in the
> RDFS:
>
> http://www.cidoc-crm.org/sites/default/files/
> 20160802PropertiesOfProperties.pptx
>
> I think I'd be very happy with this "Property Class" approach, although
> rather than using the generic properties P01_has_domain, P02_has_range, and
> their inverses,I would still want to define specific subproperties, e.g.
> for the case of actors playing a specific role in the performance of an
> activity, I would prefer to link the performance (i.e. the instance of PC14
> carried out by) to the actor and the activity using domain-specific
> properties such as has_actor and has_activity.
>
> Conal
>
> On 15 March 2018 at 04:25, Martin Doerr  wrote:
>
>> Dear All,
>>
>> Please see:http://www.cidoc-crm.org/sites/default/files/CRMpc_v1.1_0.rdfs
>> on page http://www.cidoc-crm.org/versions-of-the-cidoc-crm, plus the
>> issues discussing the solution for version 6.2 (I'll look for all
>> references).
>>
>> Best,
>>
>> martin
>>
>>
>> On 3/14/2018 12:49 PM, Conal Tuohy wrote:
>>
>>
>>
>> On 8 March 2018 at 18:02, Richard Light 
>> wrote:
>>
>>> I was thinking last night that maybe we should focus our RDF efforts on
>>> exactly this issue: the representation of the CRM primitive classes E60,
>>> E61 and E62 in RDF.  The current RDF document is becoming quite
>>> wide-ranging in its scope, and (for example) you have questioned whether
>>> certain sections belong in it.  If we concentrate on this single aspect of
>>> the broader RDF issue, I think we can produce something which is of
>>> practical value relatively quickly.  In particular, I would like to devote
>>> time to this during the Lyon meeting.
>>>
>> I applaud the idea of focusing narrowly on something so as to produce
>> some of practical value quickly!
>>
>> But I do hope that the other issues raised in that document will not be
>> set aside too long, or lost.
>>
>> In particular, it seems to me that the mapping from the CRM's "properties
>> of properties" to RDF is actually a more serious gap.
>>
>> In the CRM, there are a number of properties which are themselves the
>> domain of properties. In RDF, however, a property does not have properties
>> of its own. Incidentally, I remember years ago being able to model this
>> directly in ISO Topic Maps, but practical considerations of
>> interoperability and community dictate that RDF, despite its simpler model,
>> is the 

Re: [Crm-sig] Properties of properties in RDF

[Martin Doerr]

Dear Conal,

There is no conflict with adding subproperties. Once we have defined in 
FOL the logic of properties of properties, each PC class implies its 
base property. Hence, logically, the subproperty and any added ".1" will 
hold for the instances declared and imply the same base property. If, at 
any time we wish to connect term hierarchies of roles for the .1 
properties with partially declared subproperties, we need a 
straight-forward extension of the CRM. Any subproperty, e.g., may refine 
domain and range.


All the best,

Martin

On 3/15/2018 6:28 AM, Conal Tuohy wrote:
Thanks Martin, for the link to 
http://www.cidoc-crm.org/sites/default/files/CRMpc_v1.1_0.rdfs


This is actually very close to (and compatible with) the approach I 
suggested in my earlier email, and I'm embarrassed to say I wasn't 
aware of it at all.


I've managed to find some background material (though I had to use 
Google to find it!)


http://www.cidoc-crm.org/Issue/ID-266-reified-association-vs-sub-event 
is an archive of a relevant discussion.


http://www.cidoc-crm.org/sites/default/files/Roles.pdf presents a few 
slides showing options for modelling properties of properties, 
including the "Property Class" approach.


These slides include a nice illustration of the approach defined in 
the RDFS:


http://www.cidoc-crm.org/sites/default/files/20160802PropertiesOfProperties.pptx

I think I'd be very happy with this "Property Class" approach, 
although rather than using the generic properties P01_has_domain, 
P02_has_range, and their inverses,I would still want to define 
specific subproperties, e.g. for the case of actors playing a specific 
role in the performance of an activity, I would prefer to link the 
performance (i.e. the instance of PC14 carried out by) to the actor 
and the activity using domain-specific properties such as has_actor 
and has_activity.


Conal

On 15 March 2018 at 04:25, Martin Doerr > wrote:


Dear All,

Please
see:http://www.cidoc-crm.org/sites/default/files/CRMpc_v1.1_0.rdfs

on page http://www.cidoc-crm.org/versions-of-the-cidoc-crm
, plus the
issues discussing the solution for version 6.2 (I'll look for all
references).

Best,

martin


On 3/14/2018 12:49 PM, Conal Tuohy wrote:



On 8 March 2018 at 18:02, Richard Light
mailto:rich...@light.demon.co.uk>> wrote:

I was thinking last night that maybe we should focus our RDF
efforts on exactly this issue: the representation of the CRM
primitive classes E60, E61 and E62 in RDF.  The current RDF
document is becoming quite wide-ranging in its scope, and
(for example) you have questioned whether certain sections
belong in it.  If we concentrate on this single aspect of the
broader RDF issue, I think we can produce something which is
of practical value relatively quickly. In particular, I would
like to devote time to this during the Lyon meeting.

I applaud the idea of focusing narrowly on something so as to
produce some of practical value quickly!

But I do hope that the other issues raised in that document will
not be set aside too long, or lost.

In particular, it seems to me that the mapping from the CRM's
"properties of properties" to RDF is actually a more serious gap.

In the CRM, there are a number of properties which are themselves
the domain of properties. In RDF, however, a property does not
have properties of its own. Incidentally, I remember years ago
being able to model this directly in ISO Topic Maps, but
practical considerations of interoperability and community
dictate that RDF, despite its simpler model, is the technology of
choice today.

One example of the issue is how to model the role that
individuals play in events. If a concert performance X was P14
carried out by person Y, then this maps naturally to an RDF
triple in which the predicate is crm:P14_carried_out_by. However,
if the person carried out that activity in a particular role
(e.g. as a saxophonist) then things are more difficult. In the
CRM, the P14_carried_out_by itself has the property
P14.1_in_the_role_of, whose value could be an instance of
E55_Type: Saxophonist. This is pleasingly consistent with how the
CRM handles taxonomies in other parts of the model, but it is not
workable in RDF because the P14_carried_out_by property cannot
itself have a property.

There are a number of "work-arounds" to this issue, such as
simplying ignoring the problem and "dumbing down" the data, or
moving the locus of classification from the property to the
property value (e.g. in this case that would mean classifying the
person rather than their role; that doesn't work very well
because people 

Re: [Crm-sig] Properties of properties in RDF

[Conal Tuohy]

Thanks Martin, for the link to
http://www.cidoc-crm.org/sites/default/files/CRMpc_v1.1_0.rdfs

This is actually very close to (and compatible with) the approach I
suggested in my earlier email, and I'm embarrassed to say I wasn't aware of
it at all.

I've managed to find some background material (though I had to use Google
to find it!)

http://www.cidoc-crm.org/Issue/ID-266-reified-association-vs-sub-event is
an archive of a relevant discussion.

http://www.cidoc-crm.org/sites/default/files/Roles.pdf presents a few
slides showing options for modelling properties of properties, including
the "Property Class" approach.

These slides include a nice illustration of the approach defined in the
RDFS:

http://www.cidoc-crm.org/sites/default/files/20160802PropertiesOfProperties.pptx

I think I'd be very happy with this "Property Class" approach, although
rather than using the generic properties P01_has_domain, P02_has_range, and
their inverses,I would still want to define specific subproperties, e.g.
for the case of actors playing a specific role in the performance of an
activity, I would prefer to link the performance (i.e. the instance of PC14
carried out by) to the actor and the activity using domain-specific
properties such as has_actor and has_activity.

Conal

On 15 March 2018 at 04:25, Martin Doerr  wrote:

> Dear All,
>
> Please see:http://www.cidoc-crm.org/sites/default/files/CRMpc_v1.1_0.rdfs
> on page http://www.cidoc-crm.org/versions-of-the-cidoc-crm, plus the
> issues discussing the solution for version 6.2 (I'll look for all
> references).
>
> Best,
>
> martin
>
>
> On 3/14/2018 12:49 PM, Conal Tuohy wrote:
>
>
>
> On 8 March 2018 at 18:02, Richard Light  wrote:
>
>> I was thinking last night that maybe we should focus our RDF efforts on
>> exactly this issue: the representation of the CRM primitive classes E60,
>> E61 and E62 in RDF.  The current RDF document is becoming quite
>> wide-ranging in its scope, and (for example) you have questioned whether
>> certain sections belong in it.  If we concentrate on this single aspect of
>> the broader RDF issue, I think we can produce something which is of
>> practical value relatively quickly.  In particular, I would like to devote
>> time to this during the Lyon meeting.
>>
> I applaud the idea of focusing narrowly on something so as to produce some
> of practical value quickly!
>
> But I do hope that the other issues raised in that document will not be
> set aside too long, or lost.
>
> In particular, it seems to me that the mapping from the CRM's "properties
> of properties" to RDF is actually a more serious gap.
>
> In the CRM, there are a number of properties which are themselves the
> domain of properties. In RDF, however, a property does not have properties
> of its own. Incidentally, I remember years ago being able to model this
> directly in ISO Topic Maps, but practical considerations of
> interoperability and community dictate that RDF, despite its simpler model,
> is the technology of choice today.
>
> One example of the issue is how to model the role that individuals play in
> events. If a concert performance X was P14 carried out by person Y, then
> this maps naturally to an RDF triple in which the predicate is
> crm:P14_carried_out_by. However, if the person carried out that activity in
> a particular role (e.g. as a saxophonist) then things are more difficult.
> In the CRM, the P14_carried_out_by itself has the property
> P14.1_in_the_role_of, whose value could be an instance of E55_Type:
> Saxophonist. This is pleasingly consistent with how the CRM handles
> taxonomies in other parts of the model, but it is not workable in RDF
> because the P14_carried_out_by property cannot itself have a property.
>
> There are a number of "work-arounds" to this issue, such as simplying
> ignoring the problem and "dumbing down" the data, or moving the locus of
> classification from the property to the property value (e.g. in this case
> that would mean classifying the person rather than their role; that doesn't
> work very well because people may have many distinct roles, but it works
> better for other cases).
>
> The existing guidance would suggest defining a new "saxophone-played-by"
> property to be a rdfs:subpropertyof P14_carried_out_by. This can certainly
> work, but it's actually a poor expression of the CRM's model. It negates
> the practical benefits of having external taxonomies for this kind of
> classification. This guidance, in my opinion, makes too much of the
> apparent similarity between the CRM's properties and RDF properties. They
> are not in fact the same kind of thing, and a property which itself bears
> properties is more closely approximated in RDF not as a property but
> reified as a subject resource in its own right. A more faithful mapping of
> the CRM's abstract model to RDF would introduce a new RDFS class
> corresponding to the performance of the activity. We could then say that
> concert performance X was P14a_performed_in