Re: MARC Codes for Forms of Musical Composition

On this page:
   http://www.d-nb.de/standardisierung/formate/marc21.htm

the first item under Deutsche Ubersetzung is a PDF that is a  
translation of MARC21 into German. It has all of the MARC fixed field  
codes. Unfortunately, it is a PDF, so if anyone knows of a more  
malleable version, please speak up.

kc

Quoting Ross Singer <ross.singer@talis.com>:

> Karen, you're right, adding the actual code would be useful (the assumption
> of URIs being opaque and all).  This would also be useful for SPARQL queries
> (which what I've done here currently doesn't support, but can and should and
> will).
>
> Not sure of the best predicate -- maybe skos:notation?  Anyone have a strong
> opinion on this?
>
> I would love the German translation (and any other translations, as well!).
>  Is it for all of the MARC codes?
>
> -Ross.
>
> On Mon, Jul 5, 2010 at 8:59 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>
>> On a question of usage, would it be practical to have the MARC 2-letter
>> code as a value in the RDF? After all, that is what is the value in the MARC
>> record. If one were to turn MARC into linked data, the linking element would
>> be the code. I realize that in the ideal world the MARC2RDF would use the
>> URI provided here, but ... Perhaps either an altLabel or hiddenLabel?
>>
>> Also, there is a German translation, which I can pass along if you have the
>> time to add them.
>>
>> kc
>>
>>
>>
>> Quoting "Young,Jeff (OR)" <jyoung@oclc.org>:
>>
>>  Oops, sorry. I do seem to have some wires crossed. Let me talk to Andy
>>> Houghton to see if he can help sort out why I  believe multiple rdf:types
>>> are bad for instances.
>>>
>>> Jeff
>>>
>>> Antoine Isaac <aisaac@few.vu.nl> wrote:
>>>
>>> (moving this thread from [1] to the wider LLD list, this can be of
>>> interest beyond the XG!)
>>>
>>> Hi Jeff,
>>>
>>> I'm not sure exactly why Ross' file is OWL Full, at least in the OWL 1
>>> sense. In the validator you point to, I get the following output:
>>>
>>>
>>>     * Untyped Object Property: http://umbel.org/umbel#isAbout
>>>>    * Untyped Object Property: http://purl.org/ontology/mo/wikipedia
>>>>    * Untyped Data Property:
>>>>
>>> http://www.w3.org/2004/02/skos/core#prefLabel
>>>
>>>>    * Untyped Class: http://purl.org/ontology/mo/Genre
>>>>    * Untyped Individual: http://dbpedia.org/resource/Symphony
>>>>    * Untyped Individual:
>>>>
>>> http://id.loc.gov/authorities/sh85131473#concept
>>>
>>>>    * Untyped Individual: http://en.wikipedia.org/wiki/Symphony
>>>>
>>>
>>>
>>> It could be a aide effect of that specific validator's implementation,
>>> which expects all ontological data to be present in the source at
>>> validation time--remember that we're checking instance data here, while
>>> the primary purpose of this validator is, I expect, ontologies.
>>> Maybe if Ross had pulled the definitions for all the above constructs in
>>> his file, the problem would have vanished.
>>>
>>> Note that if you want to validate against the latest OWL2-DL, you can use
>>> http://owl.cs.manchester.ac.uk/validator/
>>> I've tried it, and it gives roughly the same results: in OWL2-DL you also
>>> have to declare explicitly the resources that you're using...
>>>
>>> Cheers,
>>>
>>> Antoine
>>>
>>> [1] http://lists.w3.org/Archives/Public/public-xg-lld/2010Jul/0000.html
>>>
>>>
>>>  The http://purl.org/NET/marccodes/muscomp/sy.rdf example assumes OWL
>>>> Full.
>>>>
>>>> http://www.mygrid.org.uk/OWL/Validator
>>>>
>>>> I think it would be better as OWL DL. This could be done by separating
>>>> the various types into separate identities using hash URIs. If anyone is
>>>> interested, I could amend the example to show how.
>>>>
>>>> As a rule, I like using OWL DL better than OWL Full because my brain
>>>> doesn't fall out nearly as often.
>>>>
>>>> http://www.w3.org/TR/owl-ref/#Sublanguage-def
>>>>
>>>> Jeff
>>>>
>>>> -----Original Message-----
>>>> From: public-xg-lld-request@w3.org [mailto:public-xg-lld-request@w3.org]
>>>> On Behalf Of Karen Coyle
>>>> Sent: Friday, July 02, 2010 10:05 AM
>>>> To: Ross Singer
>>>> Cc: public-xg-lld@w3.org; List for Working Group on Open Bibliographic
>>>> Data
>>>> Subject: Re: MARC Codes for Forms of Musical Composition
>>>>
>>>> Quoting Ross Singer<ross.singer@talis.com>:
>>>>
>>>>  Hi everybody,
>>>>>
>>>>> I just wanted to let people know I've made the MARC codes for forms of
>>>>> musical compositions (
>>>>> http://www.loc.gov/standards/valuelist/marcmuscomp.html) available as
>>>>> http://purl.org/ontology/mo/Genres.
>>>>>
>>>>
>>>> Thanks, Ross. I looked at the RDA terms [1] and interestingly type of
>>>> composition isn't one of the vocabularies that was defined in RDA. I
>>>> don't know whether that was an oversight or not -- type of composition
>>>> is included in the RDA rules, there's just no list to accompany it. So
>>>> this one may end up doing double duty: MARC and RDA.
>>>>
>>>>     kc
>>>> [1]http://metadataregistry.org/rdabrowse.htm
>>>>
>>>>
>>>>> http://purl.org/NET/marccodes/muscomp/
>>>>>
>>>>> They follow the same naming convention as they would in the MARC 008
>>>>>
>>>> or 047,
>>>>
>>>>> so it's easy to map (that is, no lookup needed) from your MARC data:
>>>>>
>>>>> http://purl.org/NET/marccodes/muscomp/sy#genre
>>>>>
>>>>> etc.
>>>>>
>>>>> The RDF is available as well:
>>>>> http://purl.org/NET/marccodes/muscomp/sy.rdf
>>>>>
>>>>>
>>>>> I'd love any feedback/suggestions/corrections/etc.
>>>>>
>>>>> Also, you can look around to see MARC country codes, geographic area
>>>>>
>>>> codes
>>>>
>>>>> and language codes.  Eventually I would like to get all of the MARC
>>>>>
>>>> codes
>>>>
>>>>> (not already modeled by LC) in there (
>>>>> http://www.loc.gov/standards/valuelist/).
>>>>>
>>>>> Thanks,
>>>>> -Ross.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Karen Coyle
>> kcoyle@kcoyle.net http://kcoyle.net
>> ph: 1-510-540-7596
>> m: 1-510-435-8234
>> skype: kcoylenet
>>
>>
>



-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Monday, 5 July 2010 15:05:26 UTC