Re: [updated] EARL 1.0 Schema

Hi Johannes,

Johannes Koch wrote:
> Shadi Abou-Zahra schrieb:
>> Hi Johannes,
>>
>> Johannes Koch wrote:
>>> Shadi Abou-Zahra schrieb:
>>>> Hi,
>>>>
>>>> Ref: <http://www.w3.org/WAI/ER/EARL10/WD-EARL10-Schema-20090223>
>>>>
>>>> An updated editor's drafts of EARL 1.0 Schema is available for 
>>>> review. Please have a close look at the new approach in the 
>>>> conformance section [1], we will need to decide if this is the 
>>>> approach to take.
>>>
>>> Looks ok to me. However it's not clear whether conforming processing 
>>> tools have to be able to process all the features described. Or are 
>>> there properties that are required for processing while others are 
>>> not? Similar for producing tools.
>>
>> OK, we can clarify the wording. The idea is that conforming processors 
>> must process all the classes and properties, as they are described in 
>> the "Validation" section:
>>  - <http://www.w3.org/WAI/ER/EARL10/WD-EARL10-Schema-20090223#validation>
>>
>> Do you agree with this approach?
> 
> Yep

OK, good.


>>>> Note that we also seem to have an issue with the current concept for 
>>>> mainAssertor [2], since foaf:member has the domain foaf:Group and 
>>>> the range foaf:Agent.
>>>
>>> So every time you use earl:mainAssertor in a triple, the subject 
>>> becomes of type foaf:Group and the object of type foaf:Agent. Is this 
>>> a problem?
>>
>> If we make earl:mainAssertor a sub-property of foaf:member, then 
>> indeed this would be the consequence. In this case it would be better 
>> to rename the property to something like mainMember or primaryMember 
>> or such.
> 
> I don't think this is necessary.

You may be right, actually. Worth a thought...


>> Another approach could be to keep both the domain and the range of the 
>> earl:mainAssertor property to be earl:Assertor (as currently defined). 
>> This would mean that both the subject and the object in such a triple 
>> would always be of type earl:Assertor.
> 
> Given the following triple
> 
> <#someAssertor> earl:mainAssertor <#someOtherAssertor>
> 
> With earl:mainAssertor being a sub-property of foaf:member and having 
> the domain and range earl:Assertor, this would imply the following 
> additional triples:
> 
> <#someAssertor> rdf:type <earl:Assertor>
> <#someAssertor> rdf:type <foaf:Group>
> <#someOtherAssertor> rdf:type <earl:Assertor>
> <#someOtherAssertor> rdf:type <foaf:Agent>

Note: #someAssertor and #someOtherAssertor are not necessarily of type 
earl:Assertor in this case (it would depend on the other triples).


> I don't see any problem. Resources can have many types.

I'm not saying that there is a problem but two different solutions. In 
the first, we ensure that the subjects and objects are type foaf:Group 
and foaf:Agent, and in the second that they are type earl:Assertor.

Having said that, the subject will usually be of type earl:Assertor due 
to the earl:assertedBy property. The object of earl:mainAssertor might 
not always be type earl:Assertor in the first option.

Any preferences for the one or other solution?


Regards,
   Shadi

-- 
Shadi Abou-Zahra - http://www.w3.org/People/shadi/ |
   WAI International Program Office Activity Lead   |
  W3C Evaluation & Repair Tools Working Group Chair |

Received on Wednesday, 25 February 2009 12:06:45 UTC