Re: Namespaces

On 8 Dec 2004, at 10:57, Phil Archer wrote:

>
> Kal,
>
> You talk much sense as ever.
>
> 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.

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

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

Cheers,

Kal

> Phil.
>
> ----- Original Message ----- From: "Kal Ahmed" <kal@techquila.com>
> To: "Phil Archer" <phil.archer@icra.org>
> Cc: "Quatro Public list" <public-quatro@w3.org>
> 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 w3.org 
>>> domain. Is this possible do you think Dan? If not, I'll set up a 
>>> purl or two (and actually host it on icra.org 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
>>>
>>> http://www.icra.org/labelsv03/rdfs/#
>>>
>>> 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:13:29 UTC