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 <rich...@light.demon.co.uk>
*Date: *Thursday, March 8, 2018 at 9:29 AM
*To: *Robert Sanderson <rsander...@getty.edu>, Martin Doerr
<mar...@ics.forth.gr>
*Cc: *George Bruseker <george.bruse...@gmail.com>, crm-sig
<crm-sig@ics.forth.gr>
*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 <crm-sig-boun...@ics.forth.gr>
<mailto:crm-sig-boun...@ics.forth.gr> on behalf of Richard Light
<rich...@light.demon.co.uk> <mailto:rich...@light.demon.co.uk>
*Date: *Thursday, March 8, 2018 at 12:02 AM
*To: *Martin Doerr <mar...@ics.forth.gr> <mailto:mar...@ics.forth.gr>
*Cc: *George Bruseker <george.bruse...@gmail.com>
<mailto:george.bruse...@gmail.com>, crm-sig <crm-sig@ics.forth.gr>
<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 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
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 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
<https://www.w3.org/TR/rdf-schema/#ch_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. Now, that there are, we should remove
"rdfs:Literal from all properties in which it is unambiguous.
I kindly ask you to check
https://www.w3.org/TR/2004/REC-rdf-mt-20040210/#dtype_interp
for compatible datatypes. This must be well-justified. E.g.,
"P57_has_number_of_parts [Number]" should have range:
"xsd:nonNegativeInteger", and not "xsd:decimal".
E60 Number could be any value from the mathematical
multidimensional spaces made of real numbers, such as RGB
images. We have no super-representation in RDFS/XSD. We can
enumerate compatible datatypes:
|"xsd:decimal|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#decimal>,
|xsd:float|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#float>,
|xsd:double|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#double>,
|xsd:hexBinary|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#hexBinary>,
|xsd:base64Binary|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#base64Binary>,
|xsd:integer|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#integer>,
|xsd:nonPositiveInteger|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#nonPositiveInteger>,
|xsd:negativeInteger|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#negativeInteger>,
|xsd:long|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#long>,
|xsd:int|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#int>,
|xsd:short|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#short>,
|xsd:byte|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#byte>,
|xsd:nonNegativeInteger|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#nonNegativeInteger>,
|xsd:unsignedLong|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedLong>,
|xsd:unsignedInt|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedInt>,
|xsd:unsignedShort|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedShort>,
|xsd:unsignedByte|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#unsignedByte>,
|xsd:positiveInteger",|
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#positiveInteger>
E61 Timeprimitive could be completely replaced by
xsd:dateTime, without causing incompatibilities if more
precision/ coverage would be needed.
"Spaceprimitive" should be a WKT string, I think.
Should E62 be xsd:string, or would that cause another outcry
to be too complex?
If someone does not convert values into xsd, is that
"incompatible"?
Best,
Martin
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email:mar...@ics.forth.gr
<mailto: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 |
--------------------------------------------------------------
--
*Richard Light*
--
*Richard Light*
