After a diversion relating to library systems expectations, I would like
to get back to the question of how to handle types, in re titles.

There are significant differences between the functionality of
properties (and sub-properties) vs. that of classes (sub-classes). Right
now, bf:workTitle is a property with a domain of bf:Work. Therefore, any
resource described with a bf:workTitle property can be inferred to be a
bf:Work. bf:instanceTitle is a property with domain of bf:Instance, so
ditto.

Therefore, in these examples:

1. <http://id.loc.gov/resources/bibs/15798171> ;
     bf:workTitle[ a bf:Title ;
             bf:titleValue"Heart of Midlothian" ] .


2. <http://id.loc.gov/resources/bibs/15798171> ;
     bf:instanceTitle[ a bf:Title ;
             bf:titleValue"The heart of Midlothian" ] .


... you can infer the class of your bib resource from the bf:xTitle
property used. If all titles become subclasses of bf:Title, then I
believe you lose this ability to infer bf:Work and bf:Instance from
these properties. *IF* the work and instance titles are good indications
of the nature of the resource being described, it would be a shame to
lose this ability. There are other properties with bf:Work and
bf:Instance as domains, such as bf:creator and bf:publicationDate, but
my non-cataloger gut feeling is that these two title properties are key
*deciders* of the nature of the entity being described.

There are other title properties that may be less significant for this
inference function: keyTitle; originPlace; originDate. Not to mention
that may of the title properties refer to parts of a title (which I find
a bit confusing in terms of how they would be bound "correctly" in an
RDF graph, but a few examples might clear that up).

All that to say that I see some problems with re-casting all types as
sub-classes, at least for some key properties where I see some useful
inferencing possibilities. However, I do not see anything in the
BIBFRAME documentation about intended inferencing, so do not know if my
inferencing assumptions are shared.

kc

On 10/27/14 12:17 PM, Robert Sanderson wrote:
>
> Hi Ray, all,
>
> Regarding the Titles and Types issues, I think there's another option
> as well, Type as Class. Or, if I may, Type as Type :)
>
> For example:
>
> _:x a bf:Work ;
> bf:title _:y .
> _:y a bf:KeyTitle ;
> rdf:value "..." .
>
>
> I believe this is desirable for the following reasons:
>
> * Type as String Value just isn't good linked data. The type should be
> uniquely distinguishable, and clearly duplicate strings could be used
> by multiple communities independently. This includes all the *Scheme
> predicates.
>
> * Type as URI Value is better, but seems pointless when the URI could
> be more efficiently used as a class. All of the bf:*Type predicates
> and bf:*Scheme predicates can just be rdf:type instead.
>
> * It makes it easier to express domain and range.
>
> * It's more readable in the RDF/XML serialization and makes any object
> mapping significantly easier.
>
> * It reduces the number of properties, thereby making it easier to see
> what's going on in the model. The subclasses are there below the main
> class for when they're needed rather than cluttering up the top level.
>
> * It's easy to create new types without needing to worry about domain
> and range of properties, just by subClassing the main class.
> Otherwise, if you want to have additional predicates associated with
> your new instance, the domain has to be the main class rather than a
> subClass, which is very poor modeling.
>
> * It simplifies many other the predicates as the main class isn't
> necessary in the predicate name, that's just the class of the object
> that the predicate is being used with. If the predicate should have
> its value constrained then it shouldn't have Literal as its range.
> For example no need for identifierValue, instead it can be just value.
>
> * It prevents the possible inconsistency of using a predicate that
> implies one type on its object, but the object has a different one (eg
> Work issn x ; x scheme "doi").
>
>
> So I think Example 2 is the closest, but a proposed Example 5:
>
> <http://example.com/xyz//Work1>
> bf:identifier [
> a bf:IssnIdentifier ;
> rdf:value "12345678" .
> ] .
>
> Where bf:IssnIdentifier is rdfs:subClassOf bf:Identifier, which is the
> range of bf:identifier.
>
> The same pattern holds for all of the classes/predicates under
> consideration.
>
> For titles:
> <http://example.com/xyz//Work1>
> bf:title [
> a bf:KeyTitle ;
> rdf:value "Lord of the Rings" .
> ] .
>
> For notes:
> <http://example.com/xyz//Work1>
> bf:note [
> a bf:AdminHistNote ;
> rdf:value "Administrative history note" .
> ] .
>
> For classifications:
> <http://example.com/xyz//Work1>
> bf:classification [
> a bf:DdcClassification ;
> rdf:value "234.5" .
> ] .
>
> For categories:
> <http://example.com/xyz//Work1>
> bf:category [
> a bf:MediaCategory ;
> rdf:value "something" .
> ] .
>
> For shelfmarks:
> <http://example.com/xyz//Work1>
> bf:shelfmark [
> a bf:DdcShelfmark ;
> rdf:value "12345678" .
> ] .
>
> Relators aren't needed as objects, and relationships between Works and
> Instances are just relationships and thus don't need fixing.
>
> Roles are not types, and thus Provider doesn't fit any of the patterns
> proposed. Roles are closer to relationships, and thus providerRole
> should be dropped. If the role is printing, then Work printer
> Provider, just like Work creator Person. If the role is associated
> with the Provider object, then it ties it exclusively to that Work so
> it could never be reused.
>
> And thus to answer the three questions:
>
> 1. Please don't do this at all :) The model should not allow
> multiple, incompatible ways to say the same thing at the same time.
> 2. Punning properties that can be either literal or a URI break tools
> and make many things, such as JSON-LD, much harder. Please don't do
> that either.
> 3. Good documentation, with contributions from the community accepted
> in a timely fashion, plus encouragement in the specification to be an
> active participant in the work.
>
> Hope that helps,
>
> Rob
>
> --
> Rob Sanderson
> Technology Collaboration Facilitator
> Digital Library Systems and Services
> Stanford, CA 94305

--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600