Could I bring up another question? I note that the property template
uses the property URI as its identifier. I believe that this may be
problematic, as the property URI is then identifying two different
things: a property, and a graph that exists in a particular profile
context. This could cause confusion in an environment where a single
property may be used in more than one profile with different attributes.
As an example, I could have two profiles, one of which has bf:title as
mandatory, the other does not. As there are no "records" in RDF, my set
of triples would have:
<bf:title><bf:Mandatory>"true"
<bf:title><bf:Mandatory>"false"
A resource template would include <bf:title> in its array of property
templates. Therefore, wouldn't bf:title be both true and false whenever
it is used in a profile?
Thanks,
kc
On 7/1/14, 2:07 AM, Svensson, Lars wrote:
> 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 http://bibframe.org/vocab/Text (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
>> "http://www.w3.org/1999/XMLSchemadate" 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.
> OK.
>
>> 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 “examplelib.org”. 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 example.com or
>>> example.org or their subdomains, e. g. library.example.org.
>> -- 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.
> OK.
>
> Best,
>
> Lars
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet
|
