Re: Namespaces

On 8 Dec 2004, at 11:30, Phil Archer wrote:

>
> [..]
>
>>>
>>> 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...)

OK - having a separate namespace for the frequency modifiers is not a 
big deal I think. So once the political decision is taken between (2) 
or (4), I can live with either of those.

>
> 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 assumption?
>

 From the point of view of the vocabulary, there shouldn't be any 
effect. From the point of view of applications, it depends on the 
semantics that Quatro will define and on whether the Quatro trust model 
is a necessary part of labelling (I mean necessary in the sense of 
"strictly necessary otherwise nothing works"). As I wrote before, trust 
plays a strong role in labelling, especially when it is not 
self-labelling, but if we have initial tools that don't process trust 
relationships using Quatro, that is probably not a big problem as long 
as the next step is to extend them to support Quatro. Does that make 
sense ? One thing though : we should be careful about changing the 
namespace URI with a new version as that *will* break existing 
implementations. I think if we only make backwards compatible changes 
to the semantics then we should probably keep the initial namespace 
URIs and only change the URI if we make a change that breaks backwards 
compatibility. But I think that is a bridge to cross when we come to 
it.

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 13:27:08 UTC