That is "kind of" true although there are workarounds, some of which are
already used in BIBFRAME - create a blank node that can have a URI
and/or a label.
You can also mix things and strings in OWL, using something called an
annotation property, but what you end up with is something that is not
This type of restriction isn't actually new, it just takes a different
form. For example, if you have a date field, in most programming
languages it needs to be either a structured string (yyyy-mm-dd) or a
free text field, but if you mix those you cannot take advantage of the
structured dates in applications. Things and strings are pretty much the
same - strings aren't "application friendly".
I agree with Kelley and others that we will need a way to punt on nearly
every place in our data where a URI would be desirable. The perfect
world where a drop-down provides the "fill-in" precisely when you need
it does not exist. It would be great to hear from anyone developing
BIBFRAME input flows on how they are handling this.
On 1/20/15 10:07 PM, Shlomo Sanders wrote:
> I agree.
> But, as far as I understand, Either a value in a triple is a "string" or it is a URI, and never the 2 shall mix.
> Sent from my iPad
>> On Jan 20, 2015, at 19:31, Bowers, Kate A. <[log in to unmask]> wrote:
>> One of the problems with making all relationships "URI" is that this is hugely time-consuming. Keying "Ken Smith, producer; Joe Jones, director; Emily Simms, presenter" is easy. Finding a record for "Ken Smith" if one doesn't already exist? Impossible level of work. We need to be able to say things in strings because we cannot possibly make all the metadata into data. Only for "traced" headings would this be possible, and we don't typically trace these all these pieces of data.
>> Kate Bowers
>> Collections Services Archivist for Metadata, Systems, and Standards
>> Harvard University Archives
>> [log in to unmask]
>> voice: (617) 384-7787
>> fax: (617) 495-8011
>> web: http://nrs.harvard.edu/urn-3:hul.eresource:archives
>> Twitter: @k8_bowers
[log in to unmask] http://kcoyle.net