Richard Cyganiak wrote:
DC is wildly inconsistent and self-contradictory in this regard. For
example, for dc:creator it says "the name of the creator should be used"
as the object, and then declares a range of dc:Agent, which obviously is
nonsense.
Yep, or http://dublincore.org/documents/dcmi-terms/#terms-source says "Recommended best
practice is to identify the related resource by means of a string conforming to a formal
identification system." vs. "This term is intended to be used with non-literal values
[...]".
Then, this would mean that the void:TechnicalFeature *has* this
format, so it would be a document, not that it *is* that format.
You read too much into this. dc:format has no domain defined, and the
prose description just says "the format of the resource", which I don't
see as conflicting with our use. You cannot conclude that X is a
document just because it has a dc:format.
I suppose you're right, it just didn't work with my interpretation of it. :-)
In summary, I agree that our examples in 1.5 are poorly chosen, and we
should use better ones. I think this is not very urgent, since the
section basically says: "Come up with your own way of identifying and
describing features. Here's an example how it could look like." Consider
it as encouragement to do better than we did ;-)
Do you think it's harmful to leave the example as is in the Guide, until
we do a future voiD 2.0?
No, I think that's ok.
How about:
:DBpedia void:feature <http://dbpedia.org/resource/RDF/XML> .
That's probably a good idea, but we don't want to specify a fixed list
of technical feature URIs for this version of voiD. Rather we want to
see what people actually use, and then decide how to move ahead. But
FWIW I personally fully support this use of DBpedia URIs.
Well, it wouldn't be a fixed list, just another example. The Turtle language
for example has its own identifier defined in its specification:
http://www.dajobe.org/2004/01/turtle/#sec-identifiers
I was always wondering about uses of this and maybe this would be the ideal
one. :-)
- My questions on
<http://code.google.com/p/void-impl/issues/detail?id=19&can=1> still
stand. ;-)
I answered in the issue tracker. Summary: Distinction between wrappers,
caching and non-caching datasets and so on are concerned with technical
implementation details, and they should be described via void:feature
(if at all) rather than via subclassing void:Dataset. As you know, we do
not provide instances to be used with void:feature at the moment, but
will consider proposals.
Ok, replied again, but you're right about the sub-classes.
- I hope there will be some alignment with SIOC in the future (see
also
<http://groups.google.com/group/sioc-dev/browse_thread/thread/da8a2d4c1f4adf38/07370433943f906d?show_docid=07370433943f906d>).
We are in principle open towards further alignment with SIOC, but this
requires clarifications from the SIOC ontology authors first, as
indicated in my mail that you linked to above. I didn't get any answers
to it, so the issue is stalled. You should lobby the SIOC folks to help
me clarify these issues, if you want to help moving this ahead.
I will try!
Thanks,
Simon
