Dear All,

Without distracting from the very active/necessary Series discussion, I’m hoping we can revitalize a few threads related to the title proposal before that ship sails away. Comments/questions/proposals below are largely based on recent modeling discussions I’ve been a part of in the the LD4L project.

1.) Title types- It’s unclear to me what a bf:VariantTitle is attempting to model from the proposal. Is it to serve as all other title types not yet defined? Rather than the bf:VariantTitle with the use of the bf:variantCharacteristic, could LOC possibly add the following to the base list of title subtypes?
  • BinderTitle
  • CaptionTitle
  • ConciseTitle (Referred to as “Portion of title” in MARC 246 documentation)
  • CoverTitle
  • DistinctiveTitle
  • RunningTitle
  • SpineTitle
  • TranslatedTitle
  • TransliteratedTitle
These cover a lot of ground and there is precedent for supporting their semantics in the library domain, http://www.loc.gov/marc/bibliographic/bd246.html. As Rob Sanderson has stated, other communities can/should continue to define more title types for specific domains.  The last two bullets above are proposed title types for titles derived from other titles rather than lifted from the work itself. Which brings me to the next thread I’d like to pick back up…

2.) Titles related to other titles- There are at least two use cases for relating titles to each other… when a title is derived from another title through translation or transliteration by the cataloger (not transcribed from the thing itself). According the BIBFRAME vocab documentation the range of bf:derivativeOf isn’t formally defined, but the rdfs:comment says otherwise, http://bibframe.org/vocab/derivativeOf.html. Could the range of the bf:derivativeOf remain undefined and the property description be rewritten to allow for reuse with any type of resource?

3.) Title parts- Could LOC add a bf:nonSort property? Or… Consider making the title parts resources themselves. I bring the latter up because sometimes works have repeating same title parts, e.g. MainTitle: Subtitle: Subtitle: PartNumber. Without these title parts modeled as resources it’s difficult to do ordering. It would be hard to tell which bf:subTitle precedes the other if they are blank nodes? If we go with modeling title parts as resources, we may want to consider reusing madsrdf:TitleElement, http://www.loc.gov/standards/mads/rdf/v1.html#TitleElement. All of this said, maybe repeating same title parts occur so infrequently that we want to stay with the more simple model for title parts.

4.) Preferred titles- As has been mentioned before, with a resource possibly having many titles, it makes sense to be able to designate one title preferred over the others in much the same way SKOS has preferred labels.  Can a sub-property bf:hasPreferredTitle be added for bf:title?

5a.) The role of transcription- Until we can scan/photograph every cultural object and make them freely available (we can dream, right?)… it would be nice to be able to note whether a title is transcribed or not. A modeling solution for transcription would be useful for other information entities (not just bf:Title).  LD4L has discussed the possibility of a SourceStatus class with named individuals, e.g. supplied, transcribed, etc., that could be the range of a property hasSourceStatus to describe information entities (not RWOs).

5b.) Alternatively, to deal with transcription- A possible solution might lie in the existing bf:descriptionSource property, but it would be worth considering adjusting the description of the property (and perhaps the domain) so that it’s clear that it can only be used to describe information entities. RWOs semantically don’t have a descriptive source so they shouldn’t be described using the bf:descriptionSource. With a range of rdfs:Resource, a URI for a specific cataloger, an index, the generic concept of cataloger could be used. Changing the property name to bf:hasDescriptionSource would help understand its directionality.

Thanks for your consideration,
Steven

————
Steven Folsom
Metadata Strategist and Standards Advocate
Cornell University Library




From: Bibliographic Framework Transition Initiative Forum on behalf of Karen Coyle
Reply-To: Bibliographic Framework Transition Initiative Forum
Date: Monday, June 22, 2015 at 10:40 PM
To: "[log in to unmask]"
Subject: Re: [BIBFRAME] BIBFRAME Title Proposal



On 6/22/15 8:27 AM, Robert Sanderson wrote:
[log in to unmask]" type="cite">


To throw in my 2c:

If a resource has some feature, that should be expressed by the resource itself.  In this case, a title is a certain type of title (for example an abbreviated title) which is not dependent on any other resource.  If it were the only bibliographic resource left in the universe, it would still be an abbreviated title.  Or for identifiers, an ISBN would still be an ISBN.  An IllustrationNote would still be an IllustrationNote.

Resources should describe themselves because they can be published by parties other than the publisher of a resource that refers to them.  Other resources might relate to them in many different ways, some of which could be inconsistent.  If the title resource didn't claim it was an AbbreviatedTitle, and two works refer to it, one with hasAbbreviatedTitle and one with hasUniformTitle ... is it abbreviated or uniform? Or both?

I may be missing your point, but when you said: "A resource should describe itself" I was thinking you were referring to the domain declaration of a property. The explicitly declared rdf:type predicate is not a resource describing itself -- it is a statement about the resource by the creator (human or otherwise) of the triple. The resource (the subject of the triple) has no control over what is said about it. I think we've got very different views, so I'll try to explain mine:

In RDF, a resource can be of more than one type.

You can say
    X a Y

and I can say
    X a F

and someone else can say
    X a Z

and now X is both Y, a F, and a Z. Since that's rather obscure, one possible example is:
Y = Parent
F = Teacher
Z = Knitter

And now X is a father, a teacher, and a knitter, unless these classes are defined as disjoint, and there's nothing to prevent piling more types on X. Therefore, by using instance triples with an explicit rdf:type (non-inferred from the domain definition) it will be easy for different communities to classify the same entity differently - to say that title1 is more than one type of title. That's a feature of RDF, not a bug.

Classes are one of the more flexible features of RDF, therefore whether you see this as a positive or a negative depends on what you are trying to accomplish. If you are wanting your entities to be able to have variability (as Allemang calls it [1], although I like the term "reusability"), then you'll be happy with that outcome. But I don't see how using explicit rdf:type can assure that you won't get different semantics for the same thing. Explicit declaration of type *will* communicate the intention of the creator of that graph, which is a Good Thing, but it doesn't prevent different views from being expressed. (The exclusive use of inferred domains is actually more of a limiting factor in terms of typing of entities.)

To your example:

lib1:work1 a bf:Work ;
  bf:hasTitle lib3:title1 .

lib2:work1 a bf:Work ;
  bf:hasTitle lib3:title1 .

lib3:title1 a bf:AbbreviatedTitle ;
  rdf:value "Abbr. ttl." .

I can add:
        lib3:title1 a bf:KeyTitle .

The same work can be described as different types in different vocabularies;

    lib1:work1 a bf:Work .
    lib2:work1 a rdf:Resource .
    lib3:work1 a frbrcore:Work .
    lib3:work1 a frbrcore:Expression .

and persons of course can be described with different classes:

    lib1:person1 a bf:Person . //a sub-sub class of bf:Authority \= foaf:Person
    lib2:person1 a foaf:Person .
    lib3:person1 a dct:Agent .

Now the question that I have is: if BF has a class "KeyTitle" what happens to bf:Title and bf:AlternateTitle? If KeyTitle a subclass of AlternateTitle? in that case, unless those classes (bf:Title and bf:AlternateTitle) are declared disjoint, RDF accepts:

   lib3:title1 a bf:KeyTitle
   [inferred lib3:title1 a bf:AlternateTitle]
   lib3:title1 a bf:Title

The title is now all an alternate title and a non-alternate title. There's some tricky design issues when types are both inferred from domain declarations and used explicitly in instance data. We can't be the first to have run into this... I'll dig through my small library of design books.

I'm still not clear, however, on the actual use case that would show which decision is best for BIBFRAME.

kc

[1] Allemang, Dean, and James A. Hendler. 2011. Semantic Web for the working ontologist effective modeling in RDFS and OWL. Waltham, MA: Morgan Kaufmann/Elsevier.
[log in to unmask]" type="cite">

[for bonus marks, the answer is both, if the ranges of the relationships were given]

Thus:

lib1:work1 a bf:Work ;
  bf:hasTitle lib3:title1 .

lib2:work1 a bf:Work ;
  bf:hasTitle lib3:title1 .

lib3:title1 a bf:AbbreviatedTitle ;
  rdf:value "Abbr. ttl." .

is, IMO, better than:

lib1:work1 a bf:Work ;
  bf:hasAbbreviatedTitle lib3:title1 .

lib2:work1 a bf:Work ;
  bf:hasUniformTitle lib3:title1 .

lib3:title1 a bf:Title ;
  rdf:value "Abbr. ttl."


Hope that helps,

Rob






On Sat, Jun 20, 2015 at 5:41 PM, Karen Coyle <[log in to unmask]> wrote:
Ray,

Part of my confusion may have been that I read that section about being questions of creating groups of classes+subclasses vs. groups of properties+subproperties. I see now that some of the arguments aren't related to that tension.

On 6/19/15 2:40 PM, Denenberg, Ray wrote:

 

> I didn't understand your statement about re-usability:

> "When a BIBFRAME bf:Title resource is created it may be a linked data

> resource that can be reused outside of BIBFRAME."

 

It's simply the age-old argument about blank nodes versus  linked data resources.  Sorry if it's stated a bit obliquely.  And I grant that it's more important in some cases than others.  Personally, I am not as offended by blank nodes as many other people are.   However, this point needs to be taken in combination with point 3 (next) to make sense, that is, if you publish it as a linked data resource, you should declare as specific a class as possible.


Declaring classes and using blank nodes are orthogonal, AFAIK. Blank nodes make use of "classness" as much as any other graph. Their difference is in whether the the subject of the graph has a name (identifier) that is stable in the open world. So I don't see what this has to do with classes, but I agree that if you expect your data to be used outside of your closed system, then named nodes are better than blank nodes. Blank nodes are fine for data you don't intend to share.

 

 

> My question about Type independently conveyed is similar. The document

> says: "Using the class to reflect the type means that the type will be known

> when it is used as such. If the type is conveyed only by the BIBFRAME

> property then that type will be known only when accessed in the BIBFRAME

> context."

> What I suspect you are referring to here is the explicit (rather than

> inferred) use of rdf:type to indicate the class of the subject - is that correct?

 

Not exactly.   Consider:

 

(1)

         -xyz     hasAbbreviatedTitle     [

 

                         a  bf: Title  ;

                         rdfs:label  "abbr. title." . ] .    

 

Versus

 

(2)

         -xyz     hasTitle   [

                         a  bf:AbbreviatedTitle 

                         rdfs:label  "abbr. title." . ]  .    

 

And let's say we create a linked data bf:Title resource in both cases. 

For (2) you'll know it's an AbbreviatedTitle. For (1) you won't.

I'm afraid that doesn't make sense to me. Can you write that out as an example. I'm not getting what you mean by "create a linked data bf:Title resource". Making the blank node a non-blank node doesn't change anything in terms of the semantics of the statements nor the operations that can be run against them, AFAIK.

 

The argument is stronger for identifiers:

 

 

(1)

         -xyz     bf:isbn    [

 

                         a  bf: Identifier  ;

                         rdf:value   "1234567890" . ] .    

 

Versus

 

(2)

         -xyz     bf:identifiedBy   [

 

                         a  bf: Isbn  ;

                         rdf:value   "1234567890" . ] .     .    

 

For (1) you don’t have a clue that it’s an Isbn, and so the value is useless.

 

(And we will have an identifier proposal out sometime hopefully soon that will propose this approach.)


If you want to search on ISBNs, a property bf:isbn is fine. There's no "knowing" here -- you are running operations such as searches against IRIs which themselves aren't meaningful. If you want to retrieve on propertyX you can do so, but the human who defines the query is the one who has to know what propertyX means. If you want to group properties by some characteristic, then using the subproperty capability seems fine. If instead you want to infer that any given subject S with predicate P is an instance of class C, then you need to use classes.

Are there use cases that use classes for the purposes of inferencing the class membership of various subjects?

kc

 

 

> If so, then it seems that a BIBFRAME "best practice" would be that types

> must always declared in the code, rather than having them be inferred, and

> perhaps that should be stated here. I am aware that many developers

> eschew inferencing because of the processing overhead, and again, if that is

> the thrust of your argument then it would be helpful for that to be stated so

> that users of BIBFRAME can follow suit.

 

I believe the jury is still out on whether this should be a BIBFRAME Best Practice.

 

 

Thanks for the comments.   --Ray


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



--
Rob Sanderson
Information Standards Advocate
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