Print

Print


Chiming in to agree with Ray that, in general, xsd:string is an appropriate
datatype for an rdf:value. And that ISBNs, in particular, are not
xsd:integers. Their value space is not aligned with that type (as defined
at [0].

Note that all literals have datatypes (see [1]). As a minor correction to
Ray's point, the default datatype for for concrete syntaxes supporting
"simple literals" is xsd:String, rather than rdfs:literal (which is not
defined).

I don't think it's correct that rdf:value is an alternative to a URI.
Indeed, it may often be useful to assign URIs to resources with declared
values (e.g. to enumerate values for later use). Apart from that, I agree
with where the group has landed on the differences from label types: labels
name resources, while values express, to some extent, /what the resource
is/.

To bring us back to the original issue: I recently read the conventions
document, and found that I couldn't understand many of the items there.
Perhaps some examples and/or motivations should be given?

Specifically, I could use clarification on:

  (2) What is meant by this? does it say more than simply "use RDF"? Is it
advising that data publishers avoid blank nodes without labels?
  (3) What is the issue of URI vs. blank node? What does it mean to have no
position? The explanation of this item seems to misunderstand blank nodes.
  (5) Does this mean to say "inverse property", rather than reciprocal?
When might a such a property be appropriate or inappropriate?

I have smaller concerns about:

  (1) Can a reason for this decision be given? Is the goal to leave the
door open for OWL-DL?
  (4) This one has a good explanation, but some loose use of language;
(e.g.  "Some advantages of representing type as class rather than
property"). Additionally, is "type" intended to mean something more
specific than class membership?
  (7) Are there examples? I think I understand this to be avoiding
properties like :isPartOfWork, :isPartOfInstance, etc..., but I'm mostly
guessing.
  (8) (As discussed in this thread).

- Tom

[0] https://www.w3.org/TR/xmlschema-2/#integer
[1] https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal



On Mon, Jun 20, 2016 at 11:45 AM, Denenberg, Ray <[log in to unmask]> wrote:

> Values of rdf:value in BIBFRAME do have a datatype:  rdfs:literal.  That
> means that unless declared otherwise, it is a string by default. Whenever
> you want, you can refine a literal
>
> e.g.
>
> (1) rdf: value  “10”
>
> (2) rdf:value  “10”^^xs:int
>
>
>
> The first is a string; the second is an integer.  But there is nowhere in
> BIBFRAME that you would refine a value of rdf:value.
>
>
>
>
>
> Consider for example a bf:Identifier. BIBFRAME prescribes that you assert
> the value of the identifier by rdf:value:
>
>
>
>        bf:identifiedBy    [  a                             bf:Isbn
>
>                                       rdf:value
> “9783110413014”   ] .
>
>
>
> “9783110413014”  is a string.  You could refine it and assert that it’s
> an integer:
>
>
>
>                          rdf:value “9783110413014”^^xs:int
>
>
>
> But you don’t want to do that because it isn’t an integer, it’s just a
> string.    And wherever rdf:value is prescribed in BIBFRAME, it is just a
> string.
>
>
>
> Someday you may be able to assert that it has datatype “isbn”….
>
>
>
>                          rdf:value “9783110413014”^^xyz:isbn
>
>
>
> … and that may facilitate processing of the isbn string.  But there is no
> such primitive datatype yet. However the statement “a bf:Isbn” would seem
> to serve that purpose.
>
>
>
> My point being that wherever rdf:value occurs, though there may not be an
> explicit primitive datatype, the actual datatype is understood by context.
>
>
>
>
>
> There are datatype properties in BIBFRAME where is makes sense to refine
> the datatype.  Take bf:count or bf:date for example
>
> Someone might declare:
>
>           bf:count   “10”
>
> and someone else declare:
>
>       bf:count   “10”^^xs:int
>
>
>
> Or
>
>             bf:date “June 20, 2016”
>
> vs:      bf:date “20160620”^^xdt:date
>
>
>
> And in both cases the second form is going to be more easily processed.
>
>
>
> But neither of these is supplied via rdf:value; they are datatype
> properties, for which rdf:value doesn’t apply.
>
>
>
> Ray
>
>
>
>
>
>
>
>
>
>
>
> *From:* Bibliographic Framework Transition Initiative Forum [mailto:
> [log in to unmask]] *On Behalf Of *Joseph Kiegel
> *Sent:* Monday, June 20, 2016 1:18 PM
>
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] FW: [BIBFRAME] rdf:value
>
>
>
> I agree.
>
>
>
> It seems that the object of rdf:value should have a datatype.  A good
> basis for a list of datatypes is the table in RDF Semantics (
> http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#DTYPEINTERP).  These types
> are widely understood.  Of course, local types can be established but they
> make widespread sharing of data more difficult.
>
>
>
> Looked at from this point of view, only one case from the examples of
> rdf:value in the BIBFRAME specifications fits an xsd datatype:  ISBNs are
> integers.  The rest do not conform to a standard datatype.
>
>
>
>
>
> *From:* Bibliographic Framework Transition Initiative Forum [
> mailto:[log in to unmask] <[log in to unmask]>] *On Behalf
> Of *Fallgren, Nancy (NIH/NLM) [E]
> *Sent:* Monday, June 20, 2016 9:24 AM
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] FW: [BIBFRAME] rdf:value
>
>
>
> At NLM, we’ve been asking the same question as Joe in re use of rdf:value
> v. rdfs:label in the BF 2.0 Item examples.  The use of rdf:value with a
> text string or with common terminology for which there should probably be a
> URI doesn’t make sense to us either.
>
>
>
> It’s pretty clear that W3C defines rdf:value as a ‘structured’ value while
> rdfs:label is for a human readable label.   But the W3C definition of
> rdf:value as an idiom with no meaning on its own, seems to indicate that it
> needs to be used within some context.  The W3C example in the Primer
> https://www.w3.org/TR/2004/REC-rdf-primer-20040210/#rdfvalue implies that
> it should have a datatype (which makes sense for a machine to understand a
> structured value) as well as another property giving context about the
> structured value.  So, if LC shelf mark has a structured/standard datatype
> that can be interpreted by machines as an LC Shelf mark, then use of
> rdf:value could make sense in that context; otherwise, it seems rdfs:label
> would be preferable.
>
>
>
> Also, best practices for sharing LD should probably not entail local
> interpretation of properties from another vocabulary.
>
>
>
> -Nancy
>
>
>
> Nancy J. Fallgren
>
> Metadata Specialist Librarian
>
> Cataloging and Metadata Management Section
>
> Technical Services Division
>
> National Library of Medicine
>
> [log in to unmask]
>
>
>
>
>
>
>
> *From:* Hubay Miklós [mailto:[log in to unmask] <[log in to unmask]>]
> *Sent:* Monday, June 20, 2016 11:46 AM
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] FW: [BIBFRAME] rdf:value
>
>
>
> Imho, the two properties are different. One is for value-declaration, and
> the other one is "may be used to *provide a human-readable version of a
> resource's name*."
>
> https://www.w3.org/TR/rdf-schema/
>
> 2016.06.20. 17:34 keltezéssel, Joseph Kiegel írta:
>
> Sorry, I meant rdfs:label.
>
>
>
> *From:* Joseph Kiegel
> *Sent:* Monday, June 20, 2016 8:34 AM
> *To:* 'Bibliographic Framework Transition Initiative Forum'
> <[log in to unmask]> <[log in to unmask]>
> *Subject:* RE: [BIBFRAME] rdf:value
>
>
>
> So is rdfs:value.  The question is:  what is the “appropriate” difference
> between the two?
>
>
>
>
>
> *From:* Bibliographic Framework Transition Initiative Forum [
> mailto:[log in to unmask] <[log in to unmask]>] *On Behalf
> Of *Robert Sanderson
> *Sent:* Monday, June 20, 2016 8:26 AM
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] rdf:value
>
>
>
> It's the value of the resource to which it's attached.
>
>
>
> On Mon, Jun 20, 2016 at 5:18 PM, Joseph Kiegel <[log in to unmask]> wrote:
>
>
>
> bf:identifiedBy [ a bf:Isbn
>
> rdf:value “9783110413014” ] .
>
> *Example 2*
>
> bf:identifiedBy [ a identifier:ABC ;
>
> rdf:value “MX3-387” ] .
>
> *Example 3*
>
> bf:identifiedBy [ a bf:Identifier ;
>
> bf:source “xyz” ;
>
> rdf:value “1234567890” ] .
>
>
>
> There is an ISBN, and its value is 9783...
>
> There is an ABC identifier, and its value is MX3-387
>
> There is an untyped identifier from source system xyz, and it's value is
> 123...
>
>
>
>
>
>
>
> *Notes*
>
> *Example 3*
>
> bf:baseMaterial [
>
> bf:code [ rdf:value “o” ;
>
> bf:source [rdf:value “marc007ng04” ] ] ;
>
> bf:note [ a bf:Note ;
>
> rdfs:label “Image printed on thick gold paper.” ] ] .
>
>
>
> There is an untyped resource, which one imagines is a Code, with value "o".
>
> There is an untyped resource, which is some sort of Source, with value
> "marc007..."
>
>
>
>
>
>
>
> *Item*
>
> *Example (truncated)*
>
> <http://bibframe.example.org/item/itemZ>
>
> bf:shelfMarkLcc [rdf:value “LB2395.C65 1991” ] ;
>
> bf:usageAndAccessPolicy [
>
> a bf:AccessPolicy ;
>
> rdf:value “unrestricted” ] .
>
>
>
> There is an LCC, and its value is LB...
>
> There is a Policy and its value is "unrestricted"
>
> Note -- this use is not very machine friendly. A better model would have
> identifiable policies, with their own URIs.
>
>
>
> HTH,
>
>
>
> Rob
>
>
>
> --
>
> Rob Sanderson
>
> Semantic Architect
>
> The Getty Trust
>
> Los Angeles, CA 90049
>
>
>
> --
>
> Hubay Miklós
>
> tájékoztató könyvtáros, könyvtárirendszer-adminisztrátor, MTMT-adminisztrátor
>
> Széchenyi István Egyetem Egyetemi Könyvtár
>
> 9026 Győr, Egyetem tér 1.
>
> Tel.: 96/613-443
>
> email: [log in to unmask]
>
>