Re: [Crm-sig] P90 etc.

2018-03-15 Thread 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] P90 etc.

2018-03-14 Thread Conal Tuohy 
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, this is taken up.”
>
>
>
> and
>
>
>
> “Whatever the vast majority is  and rdf:value does the job, I have no
> objections to its use.
> Just define precisely what you use it for. We can add that to our
> guidelines. It is already standard rdf.”
>
>
>
> Thanks,
>
>
>
> Rob
>
>
>
>
>
>
> --
> --
>  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
>
>


-- 
Conal Tuohy
http://conaltuohy.com/
@conal_tuohy
+61-466-324297

Re: [Crm-sig] P90 etc.

2018-03-08 Thread Robert Sanderson 

Something like:

Domain (in CRM terms): Symbolic Object
Range (in CRM terms): E62 String (represented as xsd:string in RDF)
Quantification: one to many

Scope Note:

This property is used to record the symbols used, with or without embedded 
markup such as HTML or other formatting instructions, to represent in digital 
form the resource that the property is associated with.

It should be regarded as a short-cut for the more fully developed path of P3 
has note with a P3.1 has type that defines the type as an inline representation 
of the resource, rather than a description or commentary about the resource.

Examples:

· The Appellation (E41) of a Person (E21) has a /value/ of “Martin”

· The Identifier (E42) of a Man Made Object (E22) has a /value/ of 
“P-1998-27”

· The Linguistic Object (E33) used to record a materials statement of a 
Man-Made Object (E2) has a /value/ of “ink on canvas”


I would say that the use is consistent across the examples I listed (other than 
the LOV datasets, about which I know nothing), with some additional usage for 
non string values that would be more closely represented in CRM with P90 has 
value. And while I would prefer consistency, I’m not proposing we do that :)

Rob

From: Martin Doerr 
Date: Thursday, March 8, 2018 at 10:46 AM
To: Robert Sanderson , Richard Light 

Cc: George Bruseker , crm-sig 
Subject: Re: [Crm-sig] P90 etc.

Dear Rob,

I am impressed:-).

Please specify the use they make of rdf:value.
Is there any other definition than that in RDFS 1.1 ?
Is the use between those examples consistent?
What precisely is it used for?
Can we define how it relates to other CRM properties?

Best,

martin

On 3/8/2018 8:26 PM, Robert Sanderson wrote:

Well … as a response to that call …

CRM implementations using rdf:value:


· The American Art Collaborative uses rdf:value, consisting of Amon 
Carter Museum of American Art, Archives of Americant Art (Smithsonian), Autry 
Museum of the American West, Colby College Museum of Art, Crystal Bridges 
Museum of American Art, Dallas Museum of Art, Indianapolis Museum of Art, 
Thomas Gilcrease Institute of American History and Art, National Portrait 
Gallery (Smithsonian), National Museum of Wildlife Art, Princeton University 
Art Museum, Smithsonian American Art Museum, Walters Art Museum, Yale Center 
for British Art

· The Getty Museum and Research Institute use rdf:value

· The National Museum of Australia uses rdf:value

· The Georgia O’Keefe Museum uses rdf:value

· Historic England uses rdf:value (IIRC, Phil can confirm or deny)


Implementers of the IIIF specifications use rdf:value for the same purpose, 
which comprises hundreds of organizations around the world, primarily in 
academia and cultural heritage.  http://iiif.io/api/presentation/

Implementers of the W3C Web Annotation Data Model use rdf:value for the same 
purpose.  https://www.w3.org/TR/annotation-model/#embedded-textual-body

According to lov.okfn.org, rdf:value is used in 44 datasets known to it , with 
4.6M occurrences.  For comparison, crm:P3_has_note has no known usage in LOV.

If you want just pure usage numbers … schema:value would probably win hands 
down. Schema is implemented in 20-30% of all web pages.  And has, relatively 
recently, made process changes to be sufficiently stable to be accepted as a 
normative reference specification by the W3C.  However the semantics are even 
less precisely defined than rdf:value, and W3C is a much more likely standards 
body than Google.

YMMV.

Rob


---

Re: [Crm-sig] P90 etc.

2018-03-08 Thread Martin Doerr 

Dear Rob,

I am impressed:-).

Please specify the use they make of rdf:value.
Is there any other definition than that in RDFS 1.1 ?
Is the use between those examples consistent?
What precisely is it used for?
Can we define how it relates to other CRM properties?

Best,

martin

On 3/8/2018 8:26 PM, Robert Sanderson wrote:


Well … as a response to that call …

CRM implementations using rdf:value:

·The American Art Collaborative uses rdf:value, consisting of Amon 
Carter Museum of American Art, Archives of Americant Art 
(Smithsonian), Autry Museum of the American West, Colby College Museum 
of Art, Crystal Bridges Museum of American Art, Dallas Museum of Art, 
Indianapolis Museum of Art, Thomas Gilcrease Institute of American 
History and Art, National Portrait Gallery (Smithsonian), National 
Museum of Wildlife Art, Princeton University Art Museum, Smithsonian 
American Art Museum, Walters Art Museum, Yale Center for British Art


·The Getty Museum and Research Institute use rdf:value

·The National Museum of Australia uses rdf:value

·The Georgia O’Keefe Museum uses rdf:value

·Historic England uses rdf:value (IIRC, Phil can confirm or deny)

Implementers of the IIIF specifications use rdf:value for the same 
purpose, which comprises hundreds of organizations around the world, 
primarily in academia and cultural heritage. 
http://iiif.io/api/presentation/


Implementers of the W3C Web Annotation Data Model use rdf:value for 
the same purpose. 
https://www.w3.org/TR/annotation-model/#embedded-textual-body


According to lov.okfn.org, rdf:value is used in 44 datasets known to 
it , with 4.6M occurrences.  For comparison, crm:P3_has_note has no 
known usage in LOV.


If you want just pure usage numbers … schema:value would probably win 
hands down. Schema is implemented in 20-30% of all web pages.  And 
has, relatively recently, made process changes to be sufficiently 
stable to be accepted as a normative reference specification by the 
W3C.  However the semantics are even less precisely defined than 
rdf:value, and W3C is a much more likely standards body than Google.


YMMV.

Rob

*From: *Richard Light 
*Date: *Thursday, March 8, 2018 at 9:29 AM
*To: *Robert Sanderson , Martin Doerr 

*Cc: *George Bruseker , crm-sig 


*Subject: *Re: [Crm-sig] P90 etc.

Rob,

I'm suggesting that we take a step back from this sort of ad hoc 
decision making, as noted two messages down.  We can come back to the 
question of which RDF properties to use once we are equipped with 
information on community practice as well as W3C/ISO norms.


If the group agrees, I propose to draft a call for examples of RDF 
practice which we can put out to the MCG and MCN lists (for the museum 
community), and to whatever library and archive lists we can find.


Richard

On 08/03/2018 16:28, 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, this is taken up.”

and

“Whatever the vast majority is  and rdf:value does the job, I have
no objections to its use.
Just define precisely what you use it for. We can add that to our
guidelines. It is already standard rdf.”

Thanks,

Rob

*From: *Crm-sig 
<mailto:crm-sig-boun...@ics.forth.gr> on behalf of Richard Light
 <mailto:rich...@light.demon.co.uk>
*Date: *Thursday, March 8, 2018 at 12:02 AM
*To: *Martin Doerr  <mailto:mar...@ics.forth.gr>
*Cc: *George Bruseker 
<mailto:george.bruse...@gmail.com>, crm-sig 
<mailto:crm-sig@ics.forth.gr>
    *Subject: *Re: [Crm-sig] P90 etc.

Martin,

Thanks for updating the string part of the RDF implementation doc.

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.

It seems to me that there are three elements which need to be
considered when recommending an approach:

  * the CRM's own view on what information should be expressible,
and how (in an abstract sense) it should be represented
  * RDF and other W3C/ISO recommendations and standards for
representing string-type information
  * the view of communities of practice on the issues involved,
and the solutions they have come up with

In particular I think it important that we should consult widely
on this i

Re: [Crm-sig] P90 etc.

2018-03-08 Thread Martin Doerr 

Dear Robert,

As I pointed out in my message:

I said "just define precisely what you use it for", and "when a good 
community practice emerges".


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?


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, this is taken up.”


and

“Whatever the vast majority is  and rdf:value does the job, I have no 
objections to its use.
Just define precisely what you use it for. We can add that to our 
guidelines. It is already standard rdf.”


Thanks,

Rob



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

Re: [Crm-sig] P90 etc.

2018-03-08 Thread Robert Sanderson 

Well … as a response to that call …

CRM implementations using rdf:value:


· The American Art Collaborative uses rdf:value, consisting of Amon 
Carter Museum of American Art, Archives of Americant Art (Smithsonian), Autry 
Museum of the American West, Colby College Museum of Art, Crystal Bridges 
Museum of American Art, Dallas Museum of Art, Indianapolis Museum of Art, 
Thomas Gilcrease Institute of American History and Art, National Portrait 
Gallery (Smithsonian), National Museum of Wildlife Art, Princeton University 
Art Museum, Smithsonian American Art Museum, Walters Art Museum, Yale Center 
for British Art

· The Getty Museum and Research Institute use rdf:value

· The National Museum of Australia uses rdf:value

· The Georgia O’Keefe Museum uses rdf:value

· Historic England uses rdf:value (IIRC, Phil can confirm or deny)


Implementers of the IIIF specifications use rdf:value for the same purpose, 
which comprises hundreds of organizations around the world, primarily in 
academia and cultural heritage.  http://iiif.io/api/presentation/

Implementers of the W3C Web Annotation Data Model use rdf:value for the same 
purpose.  https://www.w3.org/TR/annotation-model/#embedded-textual-body

According to lov.okfn.org, rdf:value is used in 44 datasets known to it , with 
4.6M occurrences.  For comparison, crm:P3_has_note has no known usage in LOV.

If you want just pure usage numbers … schema:value would probably win hands 
down. Schema is implemented in 20-30% of all web pages.  And has, relatively 
recently, made process changes to be sufficiently stable to be accepted as a 
normative reference specification by the W3C.  However the semantics are even 
less precisely defined than rdf:value, and W3C is a much more likely standards 
body than Google.

YMMV.

Rob


From: Richard Light 
Date: Thursday, March 8, 2018 at 9:29 AM
To: Robert Sanderson , Martin Doerr 
Cc: George Bruseker , crm-sig 
Subject: Re: [Crm-sig] P90 etc.

Rob,

I'm suggesting that we take a step back from this sort of ad hoc decision 
making, as noted two messages down.  We can come back to the question of which 
RDF properties to use once we are equipped with information on community 
practice as well as W3C/ISO norms.

If the group agrees, I propose to draft a call for examples of RDF practice 
which we can put out to the MCG and MCN lists (for the museum community), and 
to whatever library and archive lists we can find.

Richard
On 08/03/2018 16:28, 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, 
this is taken up.”

and

“Whatever the vast majority is  and rdf:value does the job, I have no 
objections to its use.
Just define precisely what you use it for. We can add that to our guidelines. 
It is already standard rdf.”

Thanks,

Rob


From: Crm-sig 
<mailto:crm-sig-boun...@ics.forth.gr> on behalf 
of Richard Light <mailto:rich...@light.demon.co.uk>
Date: Thursday, March 8, 2018 at 12:02 AM
To: Martin Doerr <mailto:mar...@ics.forth.gr>
Cc: George Bruseker 
<mailto:george.bruse...@gmail.com>, crm-sig 
<mailto:crm-sig@ics.forth.gr>
Subject: Re: [Crm-sig] P90 etc.


Martin,

Thanks for updating the string part of the RDF implementation doc.

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.

It seems to me that there are three elements which need to be considered when 
recommending an approach:

  *   the CRM's own view on what information should be expressible, and how (in 
an abstract sense) it should be represented
  *   RDF and other W3C/ISO recommendations and standards for representing 
string-type information
  *   the view of communities of practice on the issues involved, and the 
solutions they have come up with

In particular I think it important that we should consult widely on this issue, 
and be seen to take account of existing community practice.

Best wishes,

Richard
On 06/03/2018 17:54, Martin Doerr wrote:


Dear Richard,

It would be really great if you could join our next meeting!

We need your help to finish the RDF guidelines.
I have rewritten the string part in the google doc:



"Recording string
values

As

mentioned in point 3 above, the RDFS Schema does not implement the CRM 
primitive classes E60 Number, E61 Date or E62 Strin

Re: [Crm-sig] P90 etc.

2018-03-08 Thread Stephen Stead 
Gets my vote.

Wide is good

 

Stephen Stead

Tel +44 20 8668 3075 

Mob +44 7802 755 013

E-mail  <mailto:ste...@paveprime.com> ste...@paveprime.com

LinkedIn Profile  <https://www.linkedin.com/in/steads/> 
https://www.linkedin.com/in/steads/

 

From: Crm-sig [mailto:crm-sig-boun...@ics.forth.gr] On Behalf Of Richard Light
Sent: 08 March 2018 17:30
To: Robert Sanderson ; Martin Doerr 
Cc: George Bruseker ; crm-sig 
Subject: Re: [Crm-sig] P90 etc.

 

Rob,

I'm suggesting that we take a step back from this sort of ad hoc decision 
making, as noted two messages down.  We can come back to the question of which 
RDF properties to use once we are equipped with information on community 
practice as well as W3C/ISO norms.

If the group agrees, I propose to draft a call for examples of RDF practice 
which we can put out to the MCG and MCN lists (for the museum community), and 
to whatever library and archive lists we can find.

Richard

On 08/03/2018 16:28, 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, 
this is taken up.”

 

and

 

“Whatever the vast majority is  and rdf:value does the job, I have no 
objections to its use.
Just define precisely what you use it for. We can add that to our guidelines. 
It is already standard rdf.”

 

Thanks,

 

Rob

 

 

From: Crm-sig  <mailto:crm-sig-boun...@ics.forth.gr> 
 on behalf of Richard Light  
<mailto:rich...@light.demon.co.uk> 
List-Post: crm-sig@ics.forth.gr
Date: Thursday, March 8, 2018 at 12:02 AM
To: Martin Doerr  <mailto:mar...@ics.forth.gr> 
Cc: George Bruseker  <mailto:george.bruse...@gmail.com> 
, crm-sig  <mailto:crm-sig@ics.forth.gr> 

Subject: Re: [Crm-sig] P90 etc.

 

Martin,

Thanks for updating the string part of the RDF implementation doc.

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.

It seems to me that there are three elements which need to be considered when 
recommending an approach:

*   the CRM's own view on what information should be expressible, and how 
(in an abstract sense) it should be represented 
*   RDF and other W3C/ISO recommendations and standards for representing 
string-type information 
*   the view of communities of practice on the issues involved, and the 
solutions they have come up with 

In particular I think it important that we should consult widely on this issue, 
and be seen to take account of existing community practice.

Best wishes,

Richard

On 06/03/2018 17:54, Martin Doerr wrote:




Dear Richard,

It would be really great if you could join our next meeting!

We need your help to finish the RDF guidelines.
I have rewritten the string part in the google doc:






"Recording string


values


As

mentioned in point 3 above, the RDFS Schema does not implement the CRM 
primitive classes E60 Number, E61 Date or E62 String.  Instead it specifies 
rdfs:Literal as the range of properties which would otherwise take one of these 
values:

*
*   P3_has_note
*[String]
*
*
*   P57_has_number_of_parts
*[Number]
*
*
*   P79_beginning_is_qualified_by
*[String]
*
*
*   P80_end_is_qualified_by
*[String]
*
*
*   P81_ongoing_throughout
*[Time primitive] [but see Note 8 above and section on dates below]
*
*
*   P82_at_some_time_within
*[Time primitive] [but see Note 8 above and section on dates below]
*
*
*   P90_has_value
*[Number]
*

The

recommended RDFS implementation of the CIDOC CRM may further refine the range 
of these properties to more specific datatypes, if not yet done.


Recording


names


Apart

from the seven properties listed above, there are a number of situations where 
the fully-worked-out path to a string value leads to an unduly long chain of 
classes and properties.  For example:

E55_Type > P1_is_identified_by

> E41_Appellation > P3_has_note > E62_String

Documenting

an instance of E41_Appellation with a URI of its own, is only useful if the 
instance is expected to be either an object of discourse regardless what it 
identifies, such as etymology or name variants etc., or if it needs an extended 
content model with

Re: [Crm-sig] P90 etc.

2018-03-08 Thread Richard Light 
Rob,

I'm suggesting that we take a step back from this sort of ad hoc
decision making, as noted two messages down.  We can come back to the
question of which RDF properties to use once we are equipped with
information on community practice as well as W3C/ISO norms.

If the group agrees, I propose to draft a call for examples of RDF
practice which we can put out to the MCG and MCN lists (for the museum
community), and to whatever library and archive lists we can find.

Richard

On 08/03/2018 16:28, 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, this is taken up.”
>
>  
>
> and
>
>  
>
> “Whatever the vast majority is  and rdf:value does the job, I have no
> objections to its use.
> Just define precisely what you use it for. We can add that to our
> guidelines. It is already standard rdf.”
>
>  
>
> Thanks,
>
>  
>
> Rob
>
>  
>
>  
>
> *From: *Crm-sig  on behalf of Richard
> Light 
> *Date: *Thursday, March 8, 2018 at 12:02 AM
> *To: *Martin Doerr 
> *Cc: *George Bruseker , crm-sig
> 
> *Subject: *Re: [Crm-sig] P90 etc.
>
>  
>
> Martin,
>
> Thanks for updating the string part of the RDF implementation doc.
>
> 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.
>
> It seems to me that there are three elements which need to be
> considered when recommending an approach:
>
>   * the CRM's own view on what information should be expressible, and
> how (in an abstract sense) it should be represented
>   * RDF and other W3C/ISO recommendations and standards for
> representing string-type information
>   * the view of communities of practice on the issues involved, and
> the solutions they have come up with
>
> In particular I think it important that we should consult widely on
> this issue, and be seen to take account of existing community practice.
>
> Best wishes,
>
> Richard
>
> On 06/03/2018 17:54, Martin Doerr wrote:
>
> Dear Richard,
>
> It would be really great if you could join our next meeting!
>
> We need your help to finish the RDF guidelines.
> I have rewritten the string part in the google doc:
>
>
> "Recording string
>
>
> values
>
> As
>
> mentioned in point 3 above, the RDFS Schema does not implement the
> CRM primitive classes E60 Number, E61 Date or E62 String.  Instead
> it specifies rdfs:Literal as the range of properties which would
> otherwise take one of these values:
>
>   *  
>
> · P3_has_note
>
> ·  [String]
>
>   *  
>   *  
>
> · P57_has_number_of_parts
>
> ·  [Number]
>
>   *  
>   *  
>
> · P79_beginning_is_qualified_by
>
> ·  [String]
>
>   *  
>   *  
>
> · P80_end_is_qualified_by
>
> ·  [String]
>
>   *  
>   *  
>
> · P81_ongoing_throughout
>
> ·  [Time primitive] [but see Note 8 above and section on
> dates below]
>
>   *  
>   *  
>
> · P82_at_some_time_within
>
> ·  [Time primitive] [but see Note 8 above and section on
> dates below]
>
>   *  
>   *  
>
> · P90_has_value
>
> ·  [Number]
>
>   *  
>
> The
>
> recommended RDFS implementation of the CIDOC CRM may further
> refine the range of these properties to more specific datatypes,
> if not yet done.
>
>
> Recording
>
>
> names
>
> Apart
>
> from the seven properties listed above, there are a number of
> situations where the fully-worked-out path to a string value leads
> to an unduly long chain of classes and properties.  For example:
>
> /E55_Type > P1_is_identified_by/
>
>

Re: [Crm-sig] P90 etc.

2018-03-08 Thread Robert Sanderson 

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, 
this is taken up.”

and

“Whatever the vast majority is  and rdf:value does the job, I have no 
objections to its use.
Just define precisely what you use it for. We can add that to our guidelines. 
It is already standard rdf.”

Thanks,

Rob


From: Crm-sig  on behalf of Richard Light 

Date: Thursday, March 8, 2018 at 12:02 AM
To: Martin Doerr 
Cc: George Bruseker , crm-sig 
Subject: Re: [Crm-sig] P90 etc.


Martin,

Thanks for updating the string part of the RDF implementation doc.

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.

It seems to me that there are three elements which need to be considered when 
recommending an approach:

  *   the CRM's own view on what information should be expressible, and how (in 
an abstract sense) it should be represented
  *   RDF and other W3C/ISO recommendations and standards for representing 
string-type information
  *   the view of communities of practice on the issues involved, and the 
solutions they have come up with

In particular I think it important that we should consult widely on this issue, 
and be seen to take account of existing community practice.

Best wishes,

Richard
On 06/03/2018 17:54, Martin Doerr wrote:

Dear Richard,

It would be really great if you could join our next meeting!

We need your help to finish the RDF guidelines.
I have rewritten the string part in the google doc:


"Recording string
values

As

mentioned in point 3 above, the RDFS Schema does not implement the CRM 
primitive classes E60 Number, E61 Date or E62 String.  Instead it specifies 
rdfs:Literal as the range of properties which would otherwise take one of these 
values:

  *

· P3_has_note

·  [String]

  *
  *

· P57_has_number_of_parts

·  [Number]

  *
  *

· P79_beginning_is_qualified_by

·  [String]

  *
  *

· P80_end_is_qualified_by

·  [String]

  *
  *

· P81_ongoing_throughout

·  [Time primitive] [but see Note 8 above and section on dates below]

  *
  *

· P82_at_some_time_within

·  [Time primitive] [but see Note 8 above and section on dates below]

  *
  *

· P90_has_value

·  [Number]

  *

The

recommended RDFS implementation of the CIDOC CRM may further refine the range 
of these properties to more specific datatypes, if not yet done.
Recording
names

Apart

from the seven properties listed above, there are a number of situations where 
the fully-worked-out path to a string value leads to an unduly long chain of 
classes and properties.  For example:

E55_Type > P1_is_identified_by

> E41_Appellation > P3_has_note > E62_String

Documenting

an instance of E41_Appellation with a URI of its own, is only useful if the 
instance is expected to be either an object of discourse regardless what it 
identifies, such as etymology or name variants etc., or if it needs an extended 
content model with meaningful

parts, such as a street address.

In

cases where there is nothing more to say about the E41_Appellation, 
P1_is_identified_by

should

be replaced by rdfs:label (“rdfs:label is an instance 
of<https://www.w3.org/TR/rdf-schema/#ch_property>

rdf:Property<https://www.w3.org/TR/rdf-schema/#ch_property>

that may be used to provide a human-readable version of a resource's name”, in: 
RDF Schema 1.1)

E55_Type > rdfs:label >

rdfs:Literal<https://www.w3.org/TR/rdf-schema/#ch_literal>.

Since

RDFS does not qualify the range of rds:label further, we cannot formally make 
rdfs:label a subproperty of

P1_is_identified_by

or vice-versa. We can

only register the convention and take care that query systems retrieve labels 
together with instances of

P1_is_identified_by

. The fact that the same

name “Martin Doerr” may appear in different encodings is inevitable. It is 
recommended to use name spelling conventions from library cataloguing rules and 
SKOS properties for instances of  E55_Type.

"

Please comment!
I have discussed with George that we should make several distinctions:

Only digitized content can be stored in-line in the KB as Literal.

There must be a comparable way to point to a digitized content via URI, URL, or 
literal. All representations of Symbolic Objects in el

Re: [Crm-sig] P90 etc.

2018-03-08 Thread Martin Doerr 

Excellent!

Contributions are most welcome, in particular if they do not propose the 
most simple solution, but point to problems in practice of existing 
methods (such as structured encoding of personal names). Clearly, all 
solutions need to be associated with a practical scope, which should not 
be named "vast majority", but be a concrete application profile.
For instance, xsd:dateTime goes back I think a billion years, but not 4 
or 14 billion years. We can declare that out of scope.


Looking forward to that,

Martin

On 3/8/2018 10:02 AM, Richard Light wrote:


Martin,

Thanks for updating the string part of the RDF implementation doc.

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.


It seems to me that there are three elements which need to be 
considered when recommending an approach:


  * the CRM's own view on what information should be expressible, and
how (in an abstract sense) it should be represented
  * RDF and other W3C/ISO recommendations and standards for
representing string-type information
  * the view of communities of practice on the issues involved, and
the solutions they have come up with

In particular I think it important that we should consult widely on 
this issue, and be seen to take account of existing community practice.


Best wishes,

Richard

On 06/03/2018 17:54, Martin Doerr wrote:

Dear Richard,

It would be really great if you could join our next meeting!

We need your help to finish the RDF guidelines.
I have rewritten the string part in the google doc:


"Recording string values

As mentioned in point 3 above, the RDFS Schema does not implement the 
CRM primitive classes E60 Number, E61 Date or E62 String.  Instead it 
specifies rdfs:Literal as the range of properties which would 
otherwise take one of these values:


 *

P3_has_note [String]

 *

P57_has_number_of_parts [Number]

 *

P79_beginning_is_qualified_by [String]

 *

P80_end_is_qualified_by [String]

 *

P81_ongoing_throughout [Time primitive] [but see Note 8 above and
section on dates below]

 *

P82_at_some_time_within [Time primitive] [but see Note 8 above
and section on dates below]

 *

P90_has_value [Number]

The recommended RDFS implementation of the CIDOC CRM may further 
refine the range of these properties to more specific datatypes, if 
not yet done.



Recording names

Apart from the seven properties listed above, there are a number of 
situations where the fully-worked-out path to a string value leads to 
an unduly long chain of classes and properties.  For example:


E55_Type > P1_is_identified_by > E41_Appellation > P3_has_note > 
E62_String


Documenting an instance of E41_Appellation with a URI of its own, is 
only useful if the instance is expected to be either an object of 
discourse regardless what it identifies, such as etymology or name 
variants etc., or if it needs an extended content model with 
meaningful parts, such as a street address.


In cases where there is nothing more to say about the 
E41_Appellation, P1_is_identified_by shouldbe replaced by rdfs:label 
(“rdfs:label is an instance ofrdf:Property 
that may be used to 
provide a human-readable version of a resource's name”, in: RDF 
Schema 1.1)


E55_Type > rdfs:label > rdfs:Literal 
.


Since RDFS does not qualify the range of rds:label further, we cannot 
formally make rdfs:label a subproperty of P1_is_identified_by or 
vice-versa. We can only register the convention and take care that 
query systems retrieve labels together with instances of 
P1_is_identified_by . The fact that the same name “Martin Doerr” may 
appear in different encodings is inevitable. It is recommended to use 
name spelling conventions from library cataloguing rules and SKOS 
properties for instances of E55_Type.


"

Please comment!

I have discussed with George that we should make several distinctions:

Only digitized content can be stored in-line in the KB as Literal.

There must be a comparable way to point to a digitized content via 
URI, URL, or literal. All representations of Symbolic Objects in 
electronic form are ambiguous wrt the the intended level of symbolic 
interpretation: Is it the bits, or the Latin1 characters, or 
characters + font make up its identity?


We must distinguish between digital content of a symbolic object, a 
general "note" about an individual, and values in a mathematical/

Re: [Crm-sig] P90 etc.

2018-03-08 Thread Richard Light 
Martin,

Thanks for updating the string part of the RDF implementation doc.

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.

It seems to me that there are three elements which need to be considered
when recommending an approach:

  * the CRM's own view on what information should be expressible, and
how (in an abstract sense) it should be represented
  * RDF and other W3C/ISO recommendations and standards for representing
string-type information
  * the view of communities of practice on the issues involved, and the
solutions they have come up with

In particular I think it important that we should consult widely on this
issue, and be seen to take account of existing community practice.

Best wishes,

Richard

On 06/03/2018 17:54, Martin Doerr wrote:
> Dear Richard,
>
> It would be really great if you could join our next meeting!
>
> We need your help to finish the RDF guidelines.
> I have rewritten the string part in the google doc:
>
>
> "Recording string values
>
> As mentioned in point 3 above, the RDFS Schema does not implement the
> CRM primitive classes E60 Number, E61 Date or E62 String.  Instead it
> specifies rdfs:Literal as the range of properties which would
> otherwise take one of these values:
>
>  *
>
> P3_has_note [String]
>
>  *
>
> P57_has_number_of_parts [Number]
>
>  *
>
> P79_beginning_is_qualified_by [String]
>
>  *
>
> P80_end_is_qualified_by [String]
>
>  *
>
> P81_ongoing_throughout [Time primitive] [but see Note 8 above and
> section on dates below]
>
>  *
>
> P82_at_some_time_within [Time primitive] [but see Note 8 above and
> section on dates below]
>
>  *
>
> P90_has_value [Number]
>
> The recommended RDFS implementation of the CIDOC CRM may further
> refine the range of these properties to more specific datatypes, if
> not yet done.
>
>
> Recording names
>
> Apart from the seven properties listed above, there are a number of
> situations where the fully-worked-out path to a string value leads to
> an unduly long chain of classes and properties.  For example:
>
> E55_Type > P1_is_identified_by > E41_Appellation > P3_has_note >
> E62_String
>
> Documenting an instance of E41_Appellation with a URI of its own, is
> only useful if the instance is expected to be either an object of
> discourse regardless what it identifies, such as etymology or name
> variants etc., or if it needs an extended content model with
> meaningful parts, such as a street address.
>
> In cases where there is nothing more to say about the E41_Appellation,
> P1_is_identified_by shouldbe replaced by rdfs:label (“rdfs:label is an
> instance ofrdf:Property
> that may be used to
> provide a human-readable version of a resource's name”, in: RDF Schema
> 1.1)
>
> E55_Type > rdfs:label > rdfs:Literal
> .
>
> Since RDFS does not qualify the range of rds:label further, we cannot
> formally make rdfs:label a subproperty of P1_is_identified_by or
> vice-versa. We can only register the convention and take care that
> query systems retrieve labels together with instances of
> P1_is_identified_by . The fact that the same name “Martin Doerr” may
> appear in different encodings is inevitable. It is recommended to use
> name spelling conventions from library cataloguing rules and SKOS
> properties for instances of  E55_Type.
>
> "
>
> Please comment!
>
> I have discussed with George that we should make several distinctions:
>
> Only digitized content can be stored in-line in the KB as Literal.
>
> There must be a comparable way to point to a digitized content via
> URI, URL, or literal. All representations of Symbolic Objects in
> electronic form are ambiguous wrt the the intended level of symbolic
> interpretation: Is it the bits, or the Latin1 characters, or
> characters + font make up its identity?
>
> We must distinguish between digital content of a symbolic object, a
> general "note" about an individual, and values in a mathematical/
> physical space.
>
> I recommend NOT to recommend rdf:value:
>
>
> "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. "
>
> We definitely need a recommendation for names, regardless how complex
> it becomes.
>
> When we created the RDF version, there were no datatype
> recommendations.