Going back to the original question - although bf:title was used as an example, it is a pattern that is repeated for many properties across the vocabulary.

Many would also want to say:

<>   bf:creator   “William Shakespeare” .
<>   bf:creator   <>  .

Which if option b) is adopted would become:
<>   bf:creatorResource   <>  .

In abstract this seems fine, but when reflected across the whole vocabulary it would result in a significant overhead in the number of terms, with consequential increases in complexity of querying, maintenance and training.  I believe the overhead of dual property names would be far too high.

Coming from the world, where string is in the range of all properties by default “If you have a resource URI use it, if not a string is acceptable”, option a) is simple and obvious.

Using Rob’s suggestion for a variation to option a):
<>   bf:creator  [ rdfs:label “William Shakespeare” ].

This introduces complexity in markup, especially for humans — when do I put brackets around a string and when don’t I ?

It also introduces blank nodes, a can be seen from the triples it produces:
<> <> _:n2 .
_:n2 <> "William Shakespeare" .
Yes you could convert the blank node into a persisted resource, however that would introduce a significant processing overhead in managing, matching and deduping those resources that are crated just from a string.

I believe that questions like this need to be viewed for consistent patterns across the vocabulary and against a few scenarios:
  1. Creating original data 
  2. Converting from previous formats
  3. Processing - for display for example
  4. Query / analysis

Applying these to this particular question [brackets/blank node or not] I, personally, conclude the following:

Wrapping strings inconsistently, in brackets only sometimes, would lead to confusion, training overheads, and a significant increase in bad data.
As for my scenarios:
  1. This is where inconsistencies become an issue for cataloguers 
  2. Not a problem either way as most of this will be done programatically 
  3. Whichever technique is used there will need to be a choice in the code based upon a resource URI or a string to interpret
  4. Again SPARQL query or inferencing tools will still have to either include multiple options or coded choices.

I would vote for keeping it simple and add a string to the range of such properties.

My 2˘


On 14 May 2015, at 07:44, Owen Stephens <[log in to unmask]> wrote:

On 13 May 2015, at 19:16, Robert Sanderson <[log in to unmask]> wrote:
(c) Pick one and have a consistent model, rather than requiring content providing implementers to choose between options and consumers to implement both in order to be interoperable.  As the information in the short term will likely be created by conversion scripts, and in the future via editors, no human ever needs to manually construct the objects in the model, so there is no opportunity cost in doing the right thing.

Which could be simplified to:

(c`) Always have a resource, and allow it to be very simple wrapper around a string:

_:work bf:hasTitle [ rdf:label "Lord of the Flies" ]

+1 to consistency. I don’t think there should be multiple places to look for the title string dependent on what the implementer has chosen to do.
At a simple level having to write a SPARQL query which deals with the possibility of the title string in different places would be a real pain.

The pattern Rob describes is both consistent and extremely common across the linked data world as the way of presenting this.


Owen Stephens
Owen Stephens Consulting
Email: [log in to unmask]
Telephone: 0121 288 6936