Print

Print


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 "..." .

Rob,

The class idea is interesting and it's worth thinking through for a 
variety of cases.

I like to approach this kind of question with another question: What do 
I want to do with this data? or What do I think someone will want to do 
with this data? In particular for BIBFRAME data, I wonder how this 
decision might affect input and display. We generally think of input as 
asking us for:

title:  [      text box           ] type: {pulldown}

or:

title: [      text box           ]
keytitle: [      text box           ]

How well do these work with the class idea?

Then there's display. Will rdf:class be useful when we want to display:

title: blah blah
keytitle: blah blah

?

With classes, unless you make them all disjoint, properties can be 
instances of more than one class. How does that affect display?

I think that classes work fine for search, since you can limit a SPARQL 
search by type. Anyone see problems for search?

What other functions might be affected by this decision? Is this the 
same case as identifiers, or are there differences?

kc
>
>
> 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