[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