Print

Print


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