RE: is FRBR relevant?

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 16:33:52 UTC