> Jason, it seems that what you are suggesting is the DC terms can be
> re-used in lots of different contexts, and that is true and that is a
> Good Thing. You have to create the context to use them in, but the
> "coreness" of DC is quite deliberate in that way. Library data is much
> more about co
Whew -- just hit discard on my last message.
On Wed, Aug 12, 2009 at 9:07 PM, Karen Coyle wrote:
> then my question is: has B changed? In other words, is B of class X the
same
> as B of class Y? (Assuming that both B's have the same URI.).
"B" (for our purposes we'll say it's "http://example.org
Karen Coyle wrote:
The above looks really odd to me -- I'm not at all sure that you can
use the class Agent in that way I was of the impression that
classes are used in metadata definitions, but not in instances. Am I
wrong?
I'll answer my own question: yes, I'm wrong. Here's an example
Ross Singer wrote:
Jason clarified what I meant much better than I did, but I will take
this a step further -- the DC properties have ranges, but only 5 have
a constraint on their domain. So while dct:creator has to point at a
dct:Agent (or some equivalent), where the dct:creator property lives
Jason, it seems that what you are suggesting is the DC terms can be
re-used in lots of different contexts, and that is true and that is a
Good Thing. You have to create the context to use them in, but the
"coreness" of DC is quite deliberate in that way. Library data is much
more about control
On Wed, Aug 12, 2009 at 1:45 PM, Karen Coyle wrote:
> Ross Singer wrote:
>>
>> One of the problems here is that it doesn't begin to address the DCAM
>> -- these are 59 properties that can be reused among 22 classes, giving
>> them different semantic meaning.
>>
>
> Uh, no. That's the opposite of wh
> Ross Singer wrote:
> >
> > One of the problems here is that it doesn't begin to address the DCAM
> > -- these are 59 properties that can be reused among 22 classes,
> giving
> > them different semantic meaning.
> >
>
> Uh, no. That's the opposite of what the DC terms are about. Each term
> has a
On Wed, Aug 12, 2009 at 7:45 PM, Karen Coyle wrote:
> What I WOULD like to see is a good vocabulary of basics -- date, time,
> place, currency, etc etc etc. One place where you know you can go and find
> all of those key building blocks, so you don't have to hunt all over god's
> little acre for s
Ross Singer wrote:
One of the problems here is that it doesn't begin to address the DCAM
-- these are 59 properties that can be reused among 22 classes, giving
them different semantic meaning.
Uh, no. That's the opposite of what the DC terms are about. Each term
has a defined range -- so t
On Wed, Aug 12, 2009 at 10:48 AM, Karen Coyle wrote:
> Ross Singer wrote:
>>
>> 3) What, specifically, is missing from DCTerms that would make a MODS
>> ontology needed? What, specifically, is missing from Bibliontology or
>> MusicOntology or FOAF or SKOS, etc. that justifies a new and, in many
>>
Ross Singer wrote:
3) What, specifically, is missing from DCTerms that would make a MODS
ontology needed? What, specifically, is missing from Bibliontology or
MusicOntology or FOAF or SKOS, etc. that justifies a new and, in many
places, overlapping vocabulary? Would time be better spent trying
I'll take a stab at this, also. I was very intrigued by Chris' work
modelling MODS as an ontology. AACR2 and MODS emerged from a business
model of standardizing descriptive practice in a way that could be readily
applied and thus shared across disparate organizations. There are some
native relat
12 matches
Mail list logo
