[Crm-sig] P90 etc.

Martin Doerr martin at ics.forth.gr
Thu Mar 8 20:46:40 EET 2018


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 <richard at light.demon.co.uk>
> *Date: *Thursday, March 8, 2018 at 9:29 AM
> *To: *Robert Sanderson <RSanderson at getty.edu>, Martin Doerr 
> <martin at ics.forth.gr>
> *Cc: *George Bruseker <george.bruseker at gmail.com>, crm-sig 
> <crm-sig at 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-bounces at ics.forth.gr>
>     <mailto:crm-sig-bounces at ics.forth.gr> on behalf of Richard Light
>     <richard at light.demon.co.uk> <mailto:richard at light.demon.co.uk>
>     *Date: *Thursday, March 8, 2018 at 12:02 AM
>     *To: *Martin Doerr <martin at ics.forth.gr> <mailto:martin at ics.forth.gr>
>     *Cc: *George Bruseker <george.bruseker at gmail.com>
>     <mailto:george.bruseker at gmail.com>, crm-sig <crm-sig at ics.forth.gr>
>     <mailto:crm-sig at 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:martin at ics.forth.gr <mailto:martin at 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*
>

-- 
--------------------------------------------------------------
  Dr. Martin Doerr              |  Vox:+30(2810)391625        |
  Research Director             |  Fax:+30(2810)391638        |
                                |  Email: martin at 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           |
--------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20180308/05dffd99/attachment-0001.html>


More information about the Crm-sig mailing list