Dear Kevin,

Late thanks for your comments and clarifications. My comments inline:

> > First of all thank you for your work on the BIBFRAME Profiles. I think the
> > notion of profiles will be increasingly important in the library community,
> and
> > perhaps particularly for an exchange format like BIBFRAME that is not tied
> to
> > a specific cataloguing code. I see some overlap with the work being done
> on
> > RDF application profiles so I copy the DCMI Architecture List.
> >
> > Having studied the document on BIBFRAME Profiles [1] I have some
> > questions and hope that someone can shed some light here.
> >
> > §2.2 Resource Template
> > How do the resourceURI and the resourceLabel relate to each other? My
> first
> > understanding was that the resourceLabel is the label of the resource
> > available at the resourceURI (and thus available by dereferencing the
> > resourceURI). In the example (Fig 2.2a), however, there is the
> resourceLabel
> > Book” and the resourceURI (which is not a
> > book). Can you please expand a bit on this in the document?
> -- When Bibframe Profiles are used as cataloging templates, which is how
> they are used presently but with additional future uses to be considered
> (there has been some "validation" talk, but very little and very inconclusive),
> it is possible to alter the "labels" of classes/resources and properties for
> specific user communities.   For example, with a Bibframe Profile, you could
> use the label "Number of pages" with the property bf:extent, which, in the
> vocabulary, has a "Extent" as its label.  For the specific community cataloging
> a book, "Number of pages" is more descriptive about what is expected to be
> entered into the field versus "Extent."  So, in the example above, "bf:Text,"
> which has a label of "Text" in the vocabulary, would display to the user as
> "Book" in the editor, where Bibframe Profiles act as cataloging templates.
> Does this help clarify the idea a little?

Yes, it does. If the resource label is mainly for UI purposes, perhaps it could be a solution to change "resourceLabel" to "uiLabel" or something similar.

> > §2.5 Value datatype
> > Is there a reason not to use the XML schema datatypes, where applicable,
> > and to define RDF/OWL datatypes (subclass of rdfs:Datatype and OWL
> > Restrictions) when you need new ones? In Figure 2.5, you could just
> specify
> > xsd:date.
> -- Actually, "defaultURI" could be
> "" if you wanted it to be.  "xsd" is
> just a namespace prefix after all.   Anyways, Eric and all could provide more
> details about what was intended but the text indicates that the ISO8601 date
> would be "a variation on the ISO 8601 date standard," which is why, I
> presume, xsd:date was not used.

OK. For interoperability, pre-defined datatypes should of course be preferred. Could you add such a recommendation to the document?

> > §4 Serialisation
> > Is there a reason to restrict the available serialisations? In general you could
> > say that any existing (RDFXML, Turtle, N-Triples, JSON-LD, …) or future RDF
> > serialization is acceptable in BIBFRAME? And yes, examples please in Turtle.
> -- Just to be clear: Serialization here refers to serialization of a Bibframe
> Profile, not Bibframe resource data itself.  Correct, if Bibframe Profiles were
> expressed inTurtle then presumably any RDF serialization would also be
> viable.  Personally, I think pushing the Profile spec into Turtle would result in
> some unwieldy RDF, but I'd have to see it to know.

OK, we should try and see what happens...

> > §6.1 Default BIBFRAME Profile
> > Here I don’t understand what you mean by saying “Human readable labels
> > for the display are extracted from the RDF schema associated with the class
> > identifiers”. Which “class identifiers” do you refer to? And: If you can
> extract
> > the label by dereferencing a URI, why repeat it in the profile?
> -- The answer here is more or less the same as given in response to your
> comment about section 2.2 above. 


> The "class identifiers" are the
> resourceURIs and propertyURIs, which refer to classes and properties
> defined in the Bibframe vocabulary.  We can probably come up with a better
> way to refer to these instead of using "class identifiers," which is to say that I
> see the confusion.  The "human readable labels" are the values you see in
> that example associated with the resourceLabel and propertyLabel
> properties.  Looking at the example, however, "resourceLabel: Book" should
> really be resourceLabel: Text."  The idea was to use the same labels in the
> profile as used in the vocabulary, but - as with my comment above - it is a
> profile creator's choice to use whichever label he or she wants to use for a
> resource or property in a Profile.  For example, since the "author" property is
> repeatable, the Profile label could be "Author(s)" instead of the singular
> "Author," which /is/ the property's actual label, so that the cataloger would
> know more than one is permissible.  It’s a feature.

OK, got it. And I admit that I cannot come up with something better than "class identifiers". We'd have to work on that.

> > In the example you use the domain name “”. In order to
> make
> > sure that you do not (by accident) use a domain name actually used by
> > someone, it would be better to use the domains or
> > or their subdomains, e. g.
> -- OK, but can we agree this is a pretty minor point?  :) It's used twice, both as
> part of a dummy email address within a note field, not as part of a
> resource/property URI.

Yes, it's a minor point, but it's helpful since it shows (at least technically savvy readers) that it's really just an example and doesn't refer to any existing data.

> > §6.2 RDA as a BIBFRAME Profile
> > Shouldn’t the frbr:Item map to bf:HeldItem instead of to bf:Instance?
> -- Yes, we'll have to get the graphic updated.