Re: taglists et alia

Stasinos Konstantopoulos wrote:
> 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.

OK, let's discuss this on Monday and resolve one way or the other - like 
you, I don't have strong feelings either way.

> 
>> 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.

OK.

> 
>> 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.

I've acted on this in the editor's draft posted to the member list 
yesterday - if there's no /x then /32 is implied (or should that be the 
default? I dunno - please take a look at the text and improve at will!)

> 
>> 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.

True - which is the great strength of your overall approach, now written 
up in the grouping doc. But does there come a point where the effort 
required to use a single method actually exceed the effort required to 
define 2 or 3 better methods?

> 
>> 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.

Makes sense to me. I hope to work on the extension section next week. 
I'm trying to discipline myself to not to POWDER on Fridays - I need to 
remind myself once in a while that I do have a day job too!

P

Received on Friday, 18 April 2008 08:09:27 UTC