Re: Discussion of id.loc.gov

I think the solution is provide additional URIs _in addition_ to the URI 
for the complete specific heading.  URIs can be provided _in addition_, 
and relationships can be recorded from the concept representing the 
complete heading to those concepts representing controlled assignable 
sub-headings.  If we're clever,  machine actionable data can even be 
provided to allow you to reconstruct the complete heading from it's 
parts, so you can know which part goes with which other concept, so you 
can use the alternate terms etc.

So you can provide a seperation into logical parts _and_ a URI for the 
undivided string.  As long as the undivided string has an authority 
record though, it ABSOLUTELY needs a URI.  If you don't want that, 
you're talking about changing the structure of LCSH itself -- which is 
totally a reasonable thing to talk about, because the structure of LCSH 
is ridiculous, but it's not something that can be decided unilaterally 
by people working on alternate _representations_ of LCSH.   The goal of 
a semantic web representation of LCSH is to represent it as it actually 
is -- and as it actually is, those undivided strings are indeed 
established as unique concepts in and of themselves, by an authority 
record.  Now, you can still describe in a machine-actionable way the 
manner in which those undivided unique concepts are _related_ to the 
other concepts they are built up from, so long as those other concepts 
have authority records too.

Jonathan

Karen Coyle wrote:
> Ross, there's another problem. Many of the subheadings are themselves 
> members of controlled lists. Alternate terms for those subheadings are 
> given where the controlled list is defined. Without a separation into 
> the logical parts, there isn't a linked data way to associate the term 
> as used in the subject heading with the list from which it came.
>
> I'll give some examples soon, but quite honestly I don't think that 
> treating the main heading and subheadings as an undifferentiated string 
> is going to give us what we need. Well, not what I think we need.
>
> kc
>
> Ross Singer wrote:
>   
>> On Mon, May 18, 2009 at 5:40 PM, Weinheimer Jim <j.weinheimer_at_aur.edu> wrote:
>>
>>   
>>     
>>> Agreed. But the SKOS headings put out in id.loc.gov lack this subfield information, and is exactly the point that I (and I think Karen) were trying to make. If the subfields were in there, we would have no problem at all, but as it is, while we might be able to break the strings at the hyphens, we could not recreate the semantics, i.e. the subfields v,w,x,z. At least, not without a lot of work.
>>>
>>>     
>>>       
>> But the SKOS has not replaced the MARC.  The prefLabel is just that, a
>> human readable label.  Our machines should not be trying to bust it
>> apart and infer meaning in it, since that's the whole point of the
>> URI.
>>
>> You would instead be adding other assertions to the URI (probably
>> through a secondary vocabulary, I suppose, since SKOS can only deal
>> with NT/BT/RT) to which you can layer in the complexities of LCSH.
>>
>> This way, anybody (library and, more importantly, non-library
>> applications) can use the URIs.  People who don't understand or care
>> about the stuff we apparently can't figure out very well /ourselves/,
>> will have SKOS and a pretty simple thesaurus of related concepts.
>>
>> Libraries, armed with knowledge of this other, LCSH-specific
>> vocabulary (I don't know of any other data-structures that mimic LCSH)
>> will have the URIs, the SKOS for the obvious relationships and the
>> LCSH thing for the less so (although, possibly more machine usable
>> than they /ever/ have been).
>>
>> Everybody wins.
>>
>> -Ross.
>>
>>
>>   
>>     
>
>
>