Re: Namespaces


>> I see you've put a query after value - surely even if we drop beginsWith 
>> etc. value is needed for matches?
> The query is there because if we make matches a property rather than a 
> class, then value would not be required.

Ah, that sounds good.

>> On the issue of allOf, oneOf etc. Eric P made a suggestion for how we 
>> could resolve this. Use the Owl unionOf etc. and put it through a generic 
>> OWL processor. If we got the desired result then it would be OK to use 
>> it. If not, we know that our own RDF definition was necessary.
>> But, my thought is that if we keep the allOf, oneOf and not classes then 
>> that would give people a choice of using those or OWL? Or am I being too 
>> woolly?
> My feeling is that we do not match the semantics of OWL as we are not 
> specifying class restrictions.

OK. Unless Shimuzu San comes up with strong arugments to the contrary, 
allOf, oneOf and not stay.

>> One thing I keep forgetting to bring up again is the issue of "contains 
>> one scene of", "contains several scenes of" and "frequent scenes of". I 
>> can see arguments for this being in namespace 1 but they probably belong 
>> in 2?
> I don't think that they belong in (1) at all - (1) is just a way of 
> assigning an arbitrary RDF statements to a subject using rules. There is a 
> question of whether the frequency modifiers are generic, and so should go 
> in (2), or are ICRA specific and so go in (3). I took the view that they 
> are ICRA specific - but I can see the argument for saying that they are 
> generic really.

Frequency modifiers are definitely not ICRA-specific. If they don't fit 
comfortably in (2) then we'd need a (4) rather than putting it in (3) 
(politics comes into this...)

One more thing.

Once we have settled these issues - and I think we're 99% there subject to 
further comment from this list - we'll be starting to build some tools and 
begin some implementation. But, we know that Quatro needs to add in some 
terms to aid in building trust like URLs of databases, hashes, signatures 
etc. My assumption - and because it is an assumption I need to check this - 
that we will be able to add such terms without affecting the existing ones. 
i.e. version 1.1 will backwards compatoible with version 1.0. A valid 


>> ----- Original Message ----- From: "Kal Ahmed" <>
>> To: "Phil Archer" <>
>> Cc: "Quatro Public list" <>
>> Sent: Wednesday, December 08, 2004 10:14 AM
>> Subject: Re: Namespaces
>>> I think that there are probably three separate things each of which 
>>> should ideally have its own namespace:
>>> 1) The RDF rules mechanism for assigning properties to resources using 
>>> rule-based resource selection
>>> 2) The generic content labelling vocabulary (not ICRA-specific)
>>> 3) ICRA-specific content label vocabulary
>>> At the moment (1) and (2) are conflated in the same namespace. (3) is 
>>> currently in a separate namespace.
>>> Sorry Phil, you asked if we could get rid of one and I just added one 
>>> ;-) - but I think it is probably a clean and logical distinction to 
>>> make.
>>> So in namespace (1) we would have:
>>>   applicationRule
>>>   oneOf
>>>   allOf
>>>   not
>>>   pathApplicationRule
>>>   value  ?
>>>   beginsWith  ?
>>>   endsWith  ?
>>>   contains  ?
>>>   matches
>>> In namespace (2) :
>>>   contentLabel
>>>   category
>>>   descriptor
>>>   modifier
>>>   hasModifier
>>>   hasContentLabel
>>> In namespace (3) :
>>>   icraDescriptor
>>>   nx, lx etc. (ICRA Categories)
>>>   na, nb etc. (ICRA Descriptors)
>>>   r, s etc, (ICRA Context Modifiers)
>>>   fa, fb etc. (ICRA Frequency Modifiers)
>>> Cheers,
>>> Kal
>>> On 7 Dec 2004, at 16:28, Phil Archer wrote:
>>>> Just a quick comment on namespaces.
>>>> We need to be clear about the difference between "a label" and a 
>>>> particular label such as an ICRA label.
>>>> Kal has suggested 2 namespaces in the ruleset work, rule and uri. These 
>>>> are both very generic and should ideally be on the domain. Is 
>>>> this possible do you think Dan? If not, I'll set up a purl or two (and 
>>>> actually host it on but that won't be obvious).
>>>> Do we need two Kal? If we take your proposal and _just_ have 'matches' 
>>>> (dispensing with beginsWith, endsWith, contains and hasURL) then that 
>>>> just leaves a single thing for the uri namespace? Perhaps it can be 
>>>> included in rule or am I mixing too much up here?
>>>> The namespace for the specifically ICRA bit will be
>>>> Note the word labels, not ratings as we have used previously. (Politics 
>>>> gets everywhere. A label is meant to be objective, a rating is a 
>>>> subjective interpretation of the objective facts).
>>>> Phil.

Received on Wednesday, 8 December 2004 11:34:02 UTC