Print

Print


A clarification to the clarification:

The rdf:PlainLiteral document was created by the OWL working group because
they needed a datatype for the compact literal syntax.

Plain Literals were conceptually removed in RDF 1.1.

If a literal doesn't have an explicit type or a language tag, it is an
xsd:string.

If a literal has a language tag, it is treated as an rdf:langString.

When it comes to URIs, RDF (and OWL) allow the use of the xsd:anyURI
datatype. This is a subtype of xsd:string, and behaves like a literal.
These literals behave differently to IRIs that identify resources. For
example, a relative URI in a literal is not  resolved against the document
base, because that behavior is not always appropriate for a literal.

Simon
On Nov 17, 2015 9:59 AM, "Young,Jeff (OR)" <[log in to unmask]> wrote:

> Here is a W3C note that helped me understand the difference between URL
> and URI.
>
>
>
> http://www.w3.org/TR/uri-clarification/
>
>
>
> It feels much too late for someone to decide that URLs are non-resolvable.
>
>
>
> Note that in RDF a piece of data in quotes is an rdf:PlainLiteral, not a
> string. Here’s the spec:
>
>
>
> In the RDF specification, plain literals differ from typed literals in
> that plain literals have no datatype and can optionally have a language
> tag, indicating the natural language of the content.
>
> http://www.w3.org/TR/rdf-plain-literal/
>
>
>
> In order to be a string, it would need a datatype or language tag
> assignment like so:
>
>
>
> <subjectURI> <propertyURI> "object string"^^<
> http://www.w3.org/2001/XMLSchema#string> .
>
> or
>
> <subjectURI> <propertyURI> "object string"@en .
>
>
>
> URIs can be treated as literals using xsd:anyURI like so:
>
>
>
> <subjectURI> <propertyURI> "http://example.org/foo"^^<
> http://www.w3.org/2001/XMLSchema#anyURI> .
>
>
>
> Jeff
>
>
>
> *From:* Bibliographic Framework Transition Initiative Forum [mailto:
> [log in to unmask]] *On Behalf Of *Gordon Dunsire
> *Sent:* Tuesday, November 17, 2015 9:16 AM
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] Properties of Item proposal
>
>
>
> All
>
>
>
> The JSC Technical Working Group discussed the issue of URL vs URI in a
> paper discussed by the RDA Steering Committee a few days ago; see
> http://www.rda-jsc.org/sites/all/files/6JSC-TechnicalWG-6.pdf (page 4 and
> following). The RSC accepted recommendation 1 and is taking appropriate
> action.
>
>
>
> The basic conclusion is that a URI is a thing (RDF resource), and a URL is
> a string (non-resolvable identifier). This is reflected, I think, in the
> basic syntax of RDF: a piece of data in quotes is a string (human-readable)
> and all other data in a triple are things (machine-readable URIs). Using
> angle-bracket and quote delimiters, the two basic triple syntaxes are:
>
>
>
> <subjectURI> <propertyURI> <objectURI> .
>
> <subjectURI> <propertyURI> “object string” .
>
>
>
> I hope this paper is of use – and please let me know (as Chair of the
> Working Group) if you disagree with anything.
>
>
>
> Cheers
>
>
>
> Gordon
>
>
>
> *From:* Bibliographic Framework Transition Initiative Forum [
> mailto:[log in to unmask] <[log in to unmask]>] *On Behalf
> Of *Denenberg, Ray
> *Sent:* 16 November 2015 22:19
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] Properties of Item proposal
>
>
>
> Well of course.  You can never guarantee good behavior of an independent
> system.  I’m only saying that these are the rules we are supposed to be
> playing by.  If I encounter an object of a triple which looks like an RDF
> resource URI, I dereference it (requesting RDF), and you refuse the
> request, I’d consider that a failure.
>
>
>
> Ray
>
>
>
> *From:* Bibliographic Framework Transition Initiative Forum [
> mailto:[log in to unmask] <[log in to unmask]>] *On Behalf
> Of *LeVan,Ralph
> *Sent:* Monday, November 16, 2015 4:58 PM
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] Properties of Item proposal
>
>
>
> Ray, my VIAF server does provide RDF when asked via content negotiation.
> Today it does.  So, today triples that have a VIAF URI in them are legal,
> but tomorrow when I break content negotiation they suddenly become
> illegal?  It’s impossible for the coiner of the triple to guarantee some
> third-party server behavior.  It’s up to the consumer of the triple to
> identify those URIs that are pointers to RDF and do whatever seems
> appropriate.
>
>
>
> Ralph
>
>
>
> *From:* Bibliographic Framework Transition Initiative Forum [
> mailto:[log in to unmask] <[log in to unmask]>] *On Behalf
> Of *Denenberg, Ray
> *Sent:* Monday, November 16, 2015 4:14 PM
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] Properties of Item proposal
>
>
>
> Karen,  take this one step at a time.  Suppose I have a triple:
>
>
>
>      <some subject>   bf:someProperty   <http://someURI>
>
>
>
> Where again I am using turtle notation and I am explicitly enclosing
> http://someURI  in angle braces.   I claim that http://someURI (enclosed
> in angle braces) must be dereferenceable as RDF (meaning that there is an
> RDF representation of that resource, http://someURI, which may be one of
> many representations, and I can get that RDF representation by doing a get
> on it requesting RDF via content negotiation).
>
>
>
> Do you not agree?
>
>
>
>
>
> (And you’re saying that “RDF resource” is defined in the documents you
> cited, but that expression doesn’t even occur in any of those documents.
> Nowhere. So I’m confused.)
>
>
>
>
>
>
>
> Ray
>
>
>
> *From:* Bibliographic Framework Transition Initiative Forum [
> mailto:[log in to unmask] <[log in to unmask]>] *On Behalf
> Of *Karen Coyle
> *Sent:* Monday, November 16, 2015 3:44 PM
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] Properties of Item proposal
>
>
>
>
>
> On 11/16/15 10:37 AM, Denenberg, Ray wrote:
>
> Hi Karen – Yes there certainly is a terminology issue, particularly
> because the expression “RDF resource” does not have a formal definition,
> anywhere (that I have ever been able to find).
>
>
> Actually, Ray, the quotes I gave you in my email are indeed the formal
> definition from the W3C specifications. There is probably an even more
> formal definition somewhere using virtually unreadable notation, but I
> think that what the human-readable documents say is quite clear -- which is
> that a resource is "anything that an RDF graph describes" and that it can
> be either an IRI or a literal. I agree with you that folks often refer to
> IRIs as resources as opposed to literals, but that's a misnomer. Another
> way of saying this is "string vs. thing" but there's probably some
> ambiguity in that as well. But most importantly, as I said below, nowhere
> have I encountered any statements that there is any distinction made that
> what one obtains upon dereferencing must be "RDF". In fact, I don't know
> what that actually means.
>
> Your http://hdl.loc.gov/loc.pnp/cph.3g11323, which very clearly follows
> the rules for an IRI (and IRIs do not need to be dereferenceable) is an
> IRI. What it does or does not dereference to does not change that. You can
> treat an IRI as a literal string (I don't think there's anything in RDF to
> prevent that) -- and therefore indicate that you don't intend it to be
> actionable as an IRI. However, again, your distinction of "imply that you
> can retrieve RDF by dereferencing" is not familiar to me.
>
> kc
>
> However, whenever I encounter the expression it seems to be used in the
> sense that I’m using it.   Which is this:
>
> In any RDF triple the object is a literal or an RDF resource.  A literal
> is of course a resource; and I am making a distinction between “resource”
> and “RDF resource”.
>
> So, the object of a triple is either:
>
> 1.       a literal, in which case it’s enclosed in quotes (assuming
> turtle serialization); or
>
> 2.       not enclosed in quotes, in which case it is an RDF resource URI
> (either enclosed by curly braces or using namespace prefix notation), or a
> blank node id.
>
>
>
> For case 2, the URI can be dereferenced resulting in an RDF description or
> if it is a blank node it points to an RDF description.
>
>
> Do you agree (so far)?  If you think I’m using the expression “RDF
> resource” incorrectly then what is your definition?  If you think “RDF
> resource” and “resource” mean the same thing, I disagree, but then, I could
> be wrong, since “RDF resource” has no formal definition.  But I’m using it
> in the sense that I see it used.
>
>
>
> Anyway, having said all that, getting back to the example at hand
>
>
>
>       bf:electronicLocator  [
>
>                  a    bf:ElectronicLocator ;
>
>                   rdf:value   “http://hdl.loc.gov/loc.pnp/cph.3g11323”
> <http://hdl.loc.gov/loc.pnp/cph.3g11323%94> ] ;
>
>
>
> I maintain that it would be incorrect to instead say:
>
>
>
> bf:electronicLocator  <http://hdl.loc.gov/loc.pnp/cph.3g11323”
> <http://hdl.loc.gov/loc.pnp/cph.3g11323%94> >
>
>
>
> because that would imply that you can retrieve RDF by dereferencing
> http://hdl.loc.gov/loc.pnp/cph.3g11323 , which (as far as I know) you
> can’t.
>
>
>
> Ray
>
>
>
>
>
> *From:* Bibliographic Framework Transition Initiative Forum [
> mailto:[log in to unmask] <[log in to unmask]>] *On Behalf
> Of *Karen Coyle
> *Sent:* Sunday, November 15, 2015 8:30 PM
> *To:* [log in to unmask]
> *Subject:* Re: [BIBFRAME] Properties of Item proposal
>
>
>
>
>
> On 11/12/15 12:05 PM, Denenberg, Ray wrote:
>
> Hi Joseph – thanks for the comments and questions.  I want to address two
> points, while we are still discussing the other suggestions.
>
>
>
> bf:electronicLocator is, at present, conceived to be a datatype property;
> its expected value is a literal.  We could change that to an object
> property if that’s what people want, however, the URI would still be a
> literal, because it is not an RDF resource.   In the example, the
> electronic locator is http://hdl.loc.gov/loc.pnp/cph.3g11323 and this is
> not an RDF resource. (By RDF resource, we mean, you can dereference the URI
> and get RDF in response. You can’t for this URI.)
>
>
> Ray, can you say more about this concept of a non-resource? AFAIK, many
> URIs do not dereference to  "RDF in response", but they are still
> considered resources in RDF. I'm looking at:
>
> "90. Resource
> In an RDF context, a resource can be anything that an RDF graph describes.
> A resource can be addressed by a Unified Resource Identifier (URI)
> <http://www.w3.org/TR/2013/NOTE-ld-glossary-20130627/#uniform-resource-identifier>."
> [1]
>
> "Any IRI <http://www.w3.org/TR/rdf11-concepts/#dfn-iri> or literal
> <http://www.w3.org/TR/rdf11-concepts/#dfn-literal> *denotes* something in
> the world (the "universe of discourse"). These things are called
> *resources*. Anything can be a resource, including physical things,
> documents, abstract concepts, numbers and strings; the term is synonymous
> with "entity" as it is used in the RDF Semantics specification [RDF11-MT
> <http://www.w3.org/TR/rdf11-concepts/#bib-RDF11-MT>]."[2]
>
> There is similar language in the RDF 1.1 primer. [3]
>
> This might be a terminology issue, but even accepting a different
> terminology, I'm not aware of any distinction where a response to the
> dereferencing of an IRI must be RDF (meaning? ntriples? JSON-LD?) rather
> than any RDF:resource (e.g. a jpeg file, an html file, an avi file).
>
> kc
> [1] http://www.w3.org/TR/2013/NOTE-ld-glossary-20130627/#resource
> [2] http://www.w3.org/TR/rdf11-concepts/#resources-and-statements
> [3] http://www.w3.org/TR/rdf11-primer/
>
> If bf:electronicLocator were to be redefined as an object property, then
> instead of this:
>
>
>
> <http://bibframe.example.org/item/item5>
> <http://bibframe.example.org/item/item5>
>
>           a                                        bf:Item ;
>
>           bf:electronicLocator      “
> http://hdl.loc.gov/loc.pnp/cph.3g11323”  ;
>
> ……
>
>
>
> It might look like this:
>
>
>
> <http://bibframe.example.org/item/item5>
> <http://bibframe.example.org/item/item5>
>
>           a                                        bf:Item ;
>
>           bf:electronicLocator  [
>
>                                                    a
>    bf:ElectronicLocator ;
>
>                                                     rdf:value   “
> http://hdl.loc.gov/loc.pnp/cph.3g11323”
> <http://hdl.loc.gov/loc.pnp/cph.3g11323%94> ] ;
>
>       ……
>
>
>
> Where here we now have defined class bf:ElectronicLocator, but the URI is
> still a literal.
>
>
>
>
>
> Second, should bf:itemOf (property of item) have a reciprocal property,
> bf:hasItem (property of Instance).
>
> I don’t know; opinions are welcomed on this question.  We did not include
> it in the draft for this reason: an item knows (or should know) what
> Instance it is an Item of.  An Instance in general does not know the
> existence of all items that claim to be an item of that Instance. So if
> there were to be a property bf:hasItem, it could be used within an Instance
> to point to all items that that Instance knows about with the disclaimer
> that it doesn’t claim to point to all its items. If, as such, this would be
> useful then we can add the property.  (The same dilemma applies to
> instanceOf and hasInstance. And granted, these are both included in
> BIBFRAME 1.0.)
>
>
>
> Ray
>
>
>
>
>
> *From:* Bibliographic Framework Transition Initiative Forum [
> mailto:[log in to unmask] <[log in to unmask]>] *On Behalf
> Of *Joseph Kiegel
> *Sent:* Tuesday, November 10, 2015 1:39 PM
> *To:* [log in to unmask]
> *Subject:* [BIBFRAME] Properties of Item proposal
>
>
>
> Items in BIBFRAME may serve different purposes, which is not addressed in
> the Items proposal.  A relatively narrow purpose is to support the user
> task *obtain*, while a more complex one is to support a working
> circulation system.  The properties elaborated in the proposal are not
> sufficient even for the user task *obtain*.  Here are comments on them.
>
>
>
> bf:electronicLocator:  should the expected value be a URI?  It seems odd
> to express URLs as literals in linked data.
>
>
>
>
>
> bf:heldBy and bf:subLocation:  the MARC holdings format and many library
> systems recognize three levels of location information: organization,
> library and sublocation within a library.  BIBFRAME should support the same
> number of levels:  for example, it should add a property such as
> bf:location, which is intermediate between bf:heldBy and bf:subLocation.
>
>
>
> bf:heldBy University of Washington Libraries
>
> bf:location:  Art Library
>
> bf:subLocation:  Reference stacks
>
>
>
> bf:heldBy University of Washington Libraries
>
> bf:location:  Engineering Library
>
> bf:subLocation:  Reference stacks
>
>
>
> Without bf:location, reference or general stacks locations in different
> buildings appear to be the same.
>
>
>
>
>
> bf:itemOf:   is a reciprocal property needed?  For example, bf:hasItem, a
> property of bf:Instance with an expected value of bf:Item.
>
>
>
>
>
> Two properties are lacking from the proposal:  bf:itemStatus and
> bf:circulationCharacteristic
>
>
>
> bf:itemStatus:  it is crucial to inform users of the status of an item,
> e.g. available, checked out, missing, withdrawn, at the bindery, etc.
>
>
>
> bf:circulationCharacteristic:  another important aspect of materials is
> the general policy that governs them, e.g. circulating or library use
> only.  It is tempting to try to include this characteristic in
> bf:itemStatus, but they are independent aspects.  LUO materials may be
> missing, at the bindery or even checked out (e.g. faculty loans of
> reference materials).
>
>
>
>
>
>
>
> --
>
> Karen Coyle
>
> [log in to unmask] http://kcoyle.net
>
> m: +1-510-435-8234
>
> skype: kcoylenet/+1-510-984-3600
>
>
>
> --
>
> Karen Coyle
>
> [log in to unmask] http://kcoyle.net
>
> m: +1-510-435-8234
>
> skype: kcoylenet/+1-510-984-3600
>
>