On Tue, 2004-01-27 at 13:46, Pete Johnston wrote:
> So just to clarify, if I am using dc:identifier to provide the URI of
> the resource being described, in the terms of our model, is that URI
>
> (a) a "value URI" (= a "resource URI"), and therefore the value-resource
> is the same resource as that being described (and dc:identifier is a
> "self-referential" property); or
> (b) a "value string", and the value-resource is an identifier (a
> resource of type some:Identifier, if you like, and not the same resource
> as that being described)
>
> I think you're saying it's (b), but I just want to be sure.
No. It cannot be decided from your description. It depends on *how* you
"use dc:identifier to provide the URI". You can do that as a value
string *or* as a value URI. In RDF it will be two different statements:
<dc:identifier rdf:resource="http://..."/>
or
<dc:identifier>http:///...</dc:identifier>
So my point is that an encoding *must* (?) disambiguate between the two
cases. It can never be inferred. Well, in practice it probably can, as
there are relatively few cases where you want to use (a) (in the
dc:identifier case).
>
> Right. But, leaving aside the syntactic stuff, if I think I was also
> wondering whether there is a difficulty in the term definitions.
>
> dc:identifier is defined as "An unambiguous reference to the resource
> within a given context".
>
> and
>
> dc:relation is defined as "A reference to a related resource."
Nice observation. I agree that the intention probably is to have them
represented differently.
> If (b) above applies (i.e. the value of dc:identifier is (always) an
> identifier (a resource of type some:Identifier)), and (as seems to me to
> be the case) the value of dc:relation is (usually) a resource of some
> type other than some:Identifier (unless I happen to be talking about an
> identifier as a related resource, but let's not, for the moment....),
> then there's no contradiction there. _But_ the current text of those
> definitions would probably lead me to expect both of those properties to
> take the _same_ class of resource as value.
This is problematic. I think this was written long before the pretty
elaborated AM now under discussion was even conceived... and the problem
did not arise.
/Mikael
--
Plus ça change, plus c'est la même chose
The more things change, the more they stay the same
|