And again +1

 

Thanks,

Shlomo

 

See the all new Developer Network

Experience the all-new, singing and dancing interactive Primo brochure.

 

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Wallis,Richard
Sent: Thursday, May 14, 2015 17:55
To: [log in to unmask]
Subject: Re: [BIBFRAME] RDF dual properties

 

On 14 May 2015, at 14:38, Thomas Berger <[log in to unmask]> wrote:



For me string valued statements like
<
http://bibframe.example.com/workX>   xy:creator   “William Shakespeare”
negate the possibility of the object being an entity and therefore make
sense only within an restricted model or context xy which a priory has
agreed upon not ever needing entities as values for the "creator" predicate.

 

I kind of agree with you that in an ideal world the creator should be an entity - unfortunately in the world, we are trying to move on from, often only has strings to represent those authors, creators, publishers, places, etc.    Are you saying that we should not produce a BF representation of those works because we do not have an entity description for them?

 

I would hope, with a little pragmatism applied, we can strive towards the ideal whilst coping with the huge source of [not always ideal] legacy data.

 

===========

 

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

 

    1. Whichever technique is used there will need to be a choice in the code based upon a resource URI or a string to interpret
    1. Again SPARQL query or inferencing tools will still have to either include multiple options or coded choices.

Not sure I agree - can you explain why?

However you look at it you will have either a string or an entity, and any query will have to account for that possibility.  Therefore it is not really an influencing complexity factor as to which way you model it — dual properties — single property with URI or string — single property with blank nodes

 

 

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

Simple may depend on your perspective! As a net consumer of such data I’d say having a consistent way of marking up is the ‘simpler’ option.

 

Which is why you have to balance the concerns of data creators, consumers, processors, and those that query it, in potential real world situations.

 

I think we are in agreement that dual properties for the same thing (title, creator, etc.) is probably too much of an overhead and are now discussing alternatives for a single property approach.

 

Looking at the snippets of Turtle, its only a few extra characters, but I’m still looking for the benefit that we would get from the extra [blank node] triple it will produce in the data.

 

~Richard.