Re: is FRBR relevant?

Hi,

I'm not sure I understand Jeff's example: which Nomens would be conflated?

I'm also not sure Tom's point would argue against skosxl:Label being a subclass of frsad:Nomen.
FRSAD [1] defines a Nomen as any sign or sequence of signs that a thema [analogous to concepts] is known by, referred to, addressed at. Why would this exclude skosxl:Labels on the basis that skosxl:Labels have exactly one literal form?

Antoine


[1] http://nkos.slis.kent.edu/FRSAR/index.html


> Correct me if I'm wrong, but I think I hear Tom saying the words from
> SKOS B.2.4 are problematic for Antoine's suggested triple:
>
> skosxl:Label rdfs:subClassOf frsad:Nomen .
>
> Given B.2.4, I'm having trouble believing this example doesn't conflate
> two Nomens:
>
> ex:nomen1 a frsad:Nomen ; # could be inferred from skosxl:Label
> 	a skosxl:Label ;
> 	frsad:soundLabel ex:genericresource1 ; # content-negotiable for
> audio/* media-types
> 	skosxl:literalForm "Fire Alarm" .
>
> frsad:soundLabel a owl:ObjectProperty ;
> 	rdfs:domain frsad:Nomen ;
> 	rdfs:range owl:Thing .
>
> Should we start hoping that SKOS B.2.4 can be relaxed so frsad:Nomen
> doesn't become a specialized niche?
>
> Jeff		
>
>> -----Original Message-----
>> From: Thomas Baker [mailto:thomasbaker49@googlemail.com] On Behalf Of
>> Thomas Baker
>> Sent: Wednesday, August 11, 2010 10:44 PM
>> To: Young,Jeff (OR)
>> Cc: Karen Coyle; Jodi Schneider; public-xg-lld@w3.org
>> Subject: Re: is FRBR relevant?
>>
>> On Mon, Aug 09, 2010 at 10:19:53PM -0400, Young,Jeff (OR) wrote:
>>>>       Nomen: any sign or sequence of signs (alphanumeric
> characters,
>>>> symbols, sound, etc.) that a thema is known by, referred to, or
>>>> addressed as.
>>>
>>> "Sound" as a Nomen looks difficult to implement using skosxl:Label
>> but
>>> it's probably difficult to implement period. I doubt it's worth a
>> whole
>>> new model.
>>
>> I do not see anything obvious in the formal semantics of
>> skosxl:Label [1] to preclude its use with (serializations
>> of) sound.  It's just that "out of the box", SKOS-XL comes
>> equipped with the notion:
>>
>>      The property chain (skosxl:prefLabel, skosxl:literalForm)
>>      is a sub-property of skos:prefLabel.
>>
>> Skos:prefLabel is a sub-property of rdfs:label, and the
>> rdfs:range of rdfs:label is rdfs:Literal [2] -- but that only
>> applies to the label properties, not to the skosxl:Label
>> class itself.  I don't see any obvious arguments against
>> coining a convention to the effect that the property chain
>> "ex:soundLabel, ex:soundForm" expresses the "sonic label"
>> of a SKOS concept, with skosxl:Label as the rdfs:range of
>> ex:soundLabel. Or something to that effect...
>>
>> In favor of Antoine's suggestion of coining an ex:Nomen as
>> a superclass of skosxl:Label, on the other hand, it could be
>> argued that the convention (section B.2.4):
>>
>>      each instance of the class skosxl:Label has one and only
>>      one literal form
>>
>> imposes the provision of a literal form and thus needlessly
>> constrains the use of skosxl:Label.
>>
>> It is true that SKOS processors designed to follow the W3C
>> Recommendation would not understand any new properties,
>> classes, property chains, or other conventions, but over time,
>> it is a good thing if the language evolves.
>>
>> [1] http://www.w3.org/TR/skos-reference/#L5981
>> [2] http://www.w3.org/TR/rdf-schema/#ch_label
>>
>>>> I still don't get how skos-xl would "fix" LCSH.
>>>
>>> LCSH doesn't need "fixed" exactly. The only problem is that too many
>>> people believe the following URI identifies "the name of the thing"
>>> (i.e. the literal "World War, 1939-1945") rather than "the thing"
>> (i.e.
>>> the concept of WWII):
>>>
>>> http://id.loc.gov/authorities/sh85148273#concept
>>>
>>> Switching from skos:prefLabel to skosxl:prefLabel and coining a new
>> URI
>>> for the skosxl:Label would help clarify the difference (IMO):
>>>
>>> http://id.loc.gov/authorities/sh85148273#heading
>>
>> Coining URIs for skosxl:Labels meets other requirements.
>> For example, all of the labels in FAO's AGROVOC Concept
>> Scheme -- in AGROVOC terminology, its "lexicalizations"
>> -- are given URIs, which in turn support the declaration
>> of explicit relations between labels along the lines of
>> (simplifying from the actual triples for brevity):
>>
>>      "FAO" isAcronymFor "Food and Agricultural Organization"
>>
>> Indeed, the requirement for declaring label relations was
>> the original reason for designing SKOS-XL.
>>
>> Tom
>>
>> --
>> Thomas Baker<tbaker@tbaker.de>
>>
>
>
>
>

Received on Thursday, 12 August 2010 17:21:24 UTC