- From: Simon Reinhardt <simon.reinhardt@koeln.de>
- Date: Fri, 30 Jan 2009 17:25:40 +0000
- To: public-lod@w3.org
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
Received on Friday, 30 January 2009 17:26:49 UTC