- From: Johannes Koch <johannes.koch@fit.fraunhofer.de>
- Date: Wed, 25 Feb 2009 11:04:15 +0100
- To: ERT WG <public-wai-ert@w3.org>
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 >>> 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. > 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> I don't see any problem. Resources can have many types. -- Johannes Koch Fraunhofer Institute for Applied Information Technology FIT Web Compliance Center Schloss Birlinghoven, D-53757 Sankt Augustin, Germany Phone: +49-2241-142628 Fax: +49-2241-142065
Received on Wednesday, 25 February 2009 10:04:54 UTC