- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Fri, 30 Jan 2009 16:51:31 +0000
- To: Simon Reinhardt <simon.reinhardt@koeln.de>
- Cc: public-lod@w3.org
Simon, On 29 Jan 2009, at 21:52, Simon Reinhardt wrote: > Congratulations! Thanks! > - <http://code.google.com/p/void-impl/source/browse/trunk/liftSSM/SSM2void.xslt > > uses void:uriPattern instead of void:uriRegexPattern and so does > the example output under <http://rdfs.org/ns/void-guide#sec_4_3_Publishing_tools > >. > I really like the addition of void:uriRegexPattern! We'll batch some minor fixes to the Guide, it'll be corrected in a few days. > - I'm not so sure about the correctness of the usage of > dcterms:format under <http://rdfs.org/ns/void-guide#sec_1_5_Technical_description_features > >. First, dcterms:format requires a resources rather than a literal. 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. Well, but that's not really an excuse for us, so you are probably right that this is poor usage. > 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. 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? > 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. > - 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. > - 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. Best, Richard > What I'm especially after is using sioc:has_container instead of > dcterms:isPartOf to go from the page of an item in the dataset to > the description of the dataset (which would be a sioc:Container as > well). > I think I will just do this for now (for the project I'm working on) > since I'm providing discovery via sitemap.xml anyway. > > Cheers, > Simon >
Received on Friday, 30 January 2009 16:52:15 UTC