W3C home > Mailing lists > Public > public-powderwg@w3.org > April 2008

taglists et alia

From: Stasinos Konstantopoulos <konstant@iit.demokritos.gr>
Date: Fri, 18 Apr 2008 08:39:13 +0300
To: Phil Archer <parcher@icra.org>
Cc: public-powderwg@w3.org
Message-ID: <20080418053913.GA8870@iit.demokritos.gr>

On Mon Apr  7 20:33:51 2008 Phil Archer said:

> In your first example you've put tags and controlled vocabulary terms in 
> the same element. I'd much rather see these kept separate as currently 
> set out [1]. Also, I think having <tag /> and <taglist /> elements is 
> going to be unnecessarily confusing, no?

<taglist/> does not change anything in <tag/> and gives the opportunity
to save a few bytes. So I don't find it either unecessary or confusing,
but I have no strong feelings in its favour either. It's just a trivial
detail anyway, so, never mind.

> The DR doc currently has
> [...]
> which transforms into an OWL Class that includes a couple of 
> rdfs:seeAlso annotations with a value of rdf:resource that links to the 
> two URIs. Such an association through rdfs:seeAlso may not apply to 
> controlled vocabulary properties, hence my desire to keep tag sets and 
> descriptor sets separate.
> Make sense to you??

This makes sense. tag sets and resource sets are, indeed, two very
different animals and should be in different elements.

> As you found, and as Andrea found when he looked at it, defining 
> datatype for CIDR blocks ain't easy. I'm a little worried about the "if 
> there's no /x at the end then it's a single URI, i.e. assume x-32. But 
> Andrea seems happy with this and if everyone else is, I won't mind.

I share Andrea's intuition about how to interpret no /x.

> Can 
> we not just say wdrd:cidr is a space separated list of CIDR blocks and 
> have done with it? Probably not, I know, but I'm trying to make sure we 
> don't take on stuff we can leave alone.

Thing is, every way of grouping IRIs has to be either made into an
OWL/RDF extension or analysed into an already introduced one. The fewer
extensions POWDER asks for, the better it is.

> The extension mechanism you propose looks very neat but I'm not sure it 
> would work exactly as you have it. If you have the root element in the 
> POWDER namespace then the GRDDL transform is automatically associated 
> with the document. I think you'd need to have the root element in a 
> different namespace and then refer to an XSLT to that generated POWDER 
> [...]

I think that we stand in agreement about the essence of the process,
modulo my poor understanding of how to put things nicely in XML, GRDDL,
XSLT, and so on.

Effectively, one builds upon a previous layer of abstraction to define
the next layer. On the processing direction, these layers get peeled off
one by one, until ones reaches a document that one finds inherently
understandable without need of another interpretative transform.

Received on Friday, 18 April 2008 05:39:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:06:03 UTC