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