W3C home > Mailing lists > Public > public-lod@w3.org > January 2009

Re: [call for comments] voiD 1.0

From: Richard Cyganiak <richard@cyganiak.de>
Date: Fri, 30 Jan 2009 16:51:31 +0000
Cc: public-lod@w3.org
Message-Id: <AEBA932D-E808-464D-8A21-E2029FED48EC@cyganiak.de>
To: Simon Reinhardt <simon.reinhardt@koeln.de>

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

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:19 UTC