using rdfs:label in some cases?

[eroux]

I think it would be relevant to use rdf:label instead of :name in some cases, I'm thinking of the ones following this pattern:

bdo:personName [
    bdo:name "klong chen pa/"@bo-x-ewts ;
    bdo:personNameType bdr:PersonCommonName
]

I think there's no need for a specific property here, something like

bdo:personName [
    rdfs:label "klong chen pa/"@bo-x-ewts ;
    bdo:personNameType bdr:PersonCommonName
]

wdyt?

In the same spirit, in that particular pattern it can be puzzling to use bdo:personNameType instead of rdf:type, but maybe multiple name types ontologies will be defined?

[xristy]

I already had considered that and ended up rejecting it in favor of the idea of using rdfs:label only as a preferred displayable label for the resource and using :name uniformly elsewhere. Perhaps I was shortsighted.

Using rdf:type requires that bdr:PersonCommonName rdf:type rdfs:Class (or owl:Class) so redoing at least the :PersonNameType so that all of the individuals are subclasses rather than individuals.

I guess the net result is:

:personName [
    rdfs:label "klong chen pa/"@bo-x-ewts ;
    a :PersonCommonName
]

So the :PersonNameType gets deleted and all of the individuals get redefined as pwl:subClass :PersonName

So I guess the same needs to be done at least for :WorkTitle.

I suppose this also suggests returning to the approach in which the PlaceType is deleted and the various individuals return to being subclasses of :Place which presents a canonical taxonomy for place types?

[eroux]

For places I don't think so, as that would prevent organizing the types in a taxonomy, which looks desirable... but for the others I would say that depends on the possibility to organize them in a taxonomy: if it sounds reasonable then keeping the current approach looks like a good idea; but if they have no reason to be something else than a list, then I think it would be more clear to turn then back into Classes... wdyt?

For rdfs:label, we can certainly stick to the definition, "a human-readable version of a resource's name", I don't think our use is in contradiction... at the same time, if there are cases where we need to make a distinction between our current rdfs:label and name (I'm not sure there are), then we may want to use skos:prefLabel, or define a bdo:prefLabel... that would make our use of common vocabulary more standard... wdyt?

I think :WorkTitle is the only other case yes

[xristy]

The :name should still be used for variant names since otherwise the idea of rdfs:label being the preferred single label for a resource is lost.

I see no reason to introduce skos:prefLabel or to rename :name as :prefLabel. What am I missing?

[eroux]

I agree with you. It seems there are be a few places (like the names of the corporations or offices/roles for instance) where we may have both :name and rdfs:label at the same level, in that case we need some distinction between a preferred label (which we currently map on rdfs:label) and a general label (which we currently map on :name).

Two issues can be raised:

• first, in these cases, should the preferred name appear in both rdfs:label and :name? This is currently the case but it's easy to change
• second, it seems that we are using rdfs:label as if it had the definition of skos:prefLabel, which seems to me as something not very standard (although not in contradiction per se), so I propose to use properties a bit differently:
  • rdfs:label for the main label and :altLabel for other labels (:altLabel seems more descriptive than :name)
  • or skos:prefLabel and skos:altLabel
  • or :prefLabel and :altLabel
  • or something else...

wdyt?

[xristy]

so for now we use skos:prefLabel instead of rdfs:label as the top level preferred human readable label.

We can use skos:altLabel for the variant forms for everything except for :Person and :Work, both of which have typed labelings. For these we have :PersonName and :WorkTitle - which could be called :PersonLabel and :WorkLabel but I'm not sure how others would respond to such a break with tradition.

For :PersonName and :WorkTitle it seems sufficient and appropriate to simply use rdfs:label since we are not distinguishing the label as preferred or alt in the context of the blank node. So:

:personName [  a :PersonCommonName ;
    rdfs:label "klong chen pa/"@bo-x-ewts ]

Is the appropriate rendering.

For the typed labels it is much better to use the owl:subClass rather than a collection of type individuals. That's a great insight. Thanks!

We can use skos:hiddenLabel for clear cases of misspelled labels that we want to retain in the data.

[xristy]

For :Persons the first name in the XML doc is given as the skos:prefLabel and also should be used to populate an appropriate :PersonName so that the type information is retained. Similarly for :Works.

In these two cases there will be duplication of the labelings. For all other entities only pref or alt would be used (maybe hidden if that's worth trying to detect during migration)

[eroux]

My current approach for these two (person name and work name) was to take the first xml element as skos:prefLabel for each language tag, excluding some (like erroneous things, tbrc phonetics, etc.)... does it make sense? I have things like

    "skos:prefLabel" : [ {
      "@language" : "zh",
      "@value" : "隆钦热降巴·赤墨俄色"
    }, {
      "@language" : "bo-x-ewts",
      "@value" : "dri med 'od zer/"
    }, {
      "@language" : "en",
      "@value" : "Drime Oser"
    } ]

[xristy]

The one caveat is that we should only select the same type. So if the first name is a bo-x-ewts of type T then pick the first zh of type T, if any, otherwise do not add a preLabel for zh.

Almost all of the data is bo-x-ewts so these decisions will be rather few.

[eroux]

hmm ok... what's the reasoning behind that? I tend to see the zh label as adding some interesting data here... but I'm not particularly attached to that, I'll do it your way

[xristy]

The reasoning is that there is a cataloguing policy regarding what type of name or title is considered preferred and that has traditionally been placed first in the XML (since XML preserves order) and so if a particular type has been used on the first element then that type reflects the cataloguing policy. The presence of zh is sporadic and unless it is of the same type as the first element then it would be infelicitous to use it in the preferred position. If there is a zh perhaps further down in the list of variants with the preferred type then use that otherwise no zh needs to be promoted. The presence of sanskrit in titles is probably not of type bibliographic title (which I think is the preferred type) for Persons I don't know if there are more than a handful of sanskrit names.