Print

Print


fre 2006-03-31 klockan 12:02 +0200 skrev Thomas Baker:
> > 3.
> > "The two legacy specifications differ with regard to whether a
> > dc:creator or dc:contributor is a person (i.e., an entity), or a name
> > (i.e., a string). In "DC-Simple-in-RDF", a dc:creator is a name:"
> > 
> > We need to make sure that the issue is not limited to
> > creator/contributor.
> 
> How about:
> 
>     The two legacy specifications differ in many ways.  One
>     particularly important difference has to do with dc:creator
>     and dc:contributor are handled -- whether they are
>     represented in a modeling sense as persons (i.e., entities)
>     or as names (i.e., strings).  In "DC-Simple-in-RDF"...

No, not really ... :-)

My point was that dc:creator/contributor were not the only properties
affected - for example dc:date will also be affected. More like

"The two legacy specifications differ with regard to whether properties
such as dc:creator or dc:date have values that are resources (e.g., a
Person or a Date), or a string representing the resource (i.e., a value
string). In "DC-Simple-in-RDF", a dc:creator is a name:"

or similar.

> 
> > 5.
> > "The range "Literal" would be reserved for metadata terms which are
> > typically associated with value strings, such as dc:title."
> > 
> > Actually, we have not committed to restricting dc:title to literal
> > values at this point. In fact, we are considering leaving the range open
> > to allow for, for example, variants of the "same" name described by a
> > single statement using multiple value strings (with different languages,
> > for example).
> 
> How about:
> 
>     If it is used at all, the range "Literal" would apply only
>     to metadata terms which are typically associated with value
>     strings, such as dc:title.

That's fine for the moment.

> > 7.
> > "to ensure the long-term viability of Dublin Core in RDF."
> > 
> > Note that the issue is limited to RDF. The other DC syntaxes are *not*
> > affected by the issue.
> > 
> > (Except possibly some Vocabulary Encoding Schemes will need to be made
> > sub-classes of the range of the respective property?)
> 
> Is that just a parenthetical note, or are you proposing a change
> in wording -- have left the same for now...

Not a change in wording, no. Just a note that as we introduce classes
for ranges, we might want to add sub-class relations to some of the
existing VESs.

/Mikael

> 
> Tom
> 
-- 
Plus ça change, plus c'est la même chose