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
<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:[email protected] |
|
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*
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: [email protected] |
|
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 |
--------------------------------------------------------------
