One of the reasons that I see for profliferation of predicates and
properties is the difficulty of understanding exactly what a metadata
term means. Most metadata sets that I have encountered use very terse
and somewhat vague definitions for their terms. I realize that there
is a danger of over-defining one's terms, but it's seldom that I feel
I know exactly what the creators intended, nor what my target metadata
creators and users will understand. I don't know whether that means we
need better definitions or a more thorough description of the context
for the metadata properties. Some examples:
DCterms title: A name given to the resource.
- Given that resource is defined as it is meant in the RDF
documentation (I'm saying that from memory -- it can't find that
statement in the DCMI Metadata Terms document), it seems that this
could be used for any noun in any vocabulary. Since the term "name"
isn't defined, it isn't clear how to distinguish this from rdfs:label.
Is it ok to use title in this way? I honestly don't know.
BIBO used dcterms:title and adds this annotation:
* scopeNote: "Used to describe the title of a bibliographic
resource" (en) That seems to be narrower than the actual DC
definition. Does it represent an earlier version? An interpretation by
the creators of BIBO? (I actually think this is the meaning that many
users of DC assume.)
Property: foaf:name A name for some thing.
- This sure sounds like "A name given to the resource" -- is
foaf:name interchangeable with dcterms:title? More importantly, is
this what is *intended* with foaf:name?
Personally, if I can't satisfactorily answer the question: "what does
this metadata element MEAN?" then I am not comfortable using it in my
work.
kc
Quoting Paul Houle <[log in to unmask]>:
> Hi, I'm working on vocabulary for RDFa metadata on
>
> http://ookaboo.com/
>
> and have run into a little problem.
>
> Now, if we look at a page like
>
> http://ookaboo.com/o/pictures/topic/170657/NASA
>
> That's a URL for a web page, but there's an informative URL
>
> http://ookaboo.com/o/pictures/topic/170657/NASA#it
>
> which represents "NASA" itself. Then I could say
>
> ookaboo:/topic/170657/NASA dcterms:subject ookaboo:/topic/17067/NASA#it.
>
> or
>
> ookaboo:/topic/170657/NASA dcterms:subject dbpedia:NASA
>
> for that matter. Now, quite a few well-respected vocabularies
> define sub-properties of dcterms:subject. For instance, sioc:topic
> and previously skos:subject. Subproperties such as sioc:topic seem
> to add no value in my book, but as a content publisher I've always
> got the anxiety that content consumers are going to accept one
> predicate and not accept the other.
>
> Now, there's also foaf:topic, which one could argue is an
> improvement on dcterms:subject, since it specifies reasonable
> domain and range limits. FOAF also includes foaf:primaryTopic which
> is a further extension of the concept. foaf:topic doesn't have any
> official relationship to dcterms:subject, but practically it almost
> means the same thing... If I was designing something to accept RDF
> from the outside world, I'd probably treat these the same way,
> perhaps putting some priority on foaf:topic, since having the range
> limited to a resource is a good thing.
>
> BIBO, at the very least, takes a reasonable stand on this and
> avoids some of the worst sorts of proliferation: it picks
> dcterms:subject instead of defining its own, and also uses some
> terms from FOAF such as foaf:Person, but it rejects foaf:topic.
>
> As both a consumer and producer of linked data, I'm disturbed by
> the "multiple ways to say things" -- I'm more interested in building
> systems that work than in compliance to particular standards. As a
> consumer, I feel like I have to accept anything I might find, but
> as a producer, I can easily see an exponential explosion of triples
> that I publish if I tried to publish every reasonable version of
> what I'm trying to say.
>
> Any thoughts?
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet
|