See also: IRC log
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2009Jun/0004.html
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2009Jun/0000
<shadi> http://xmlns.com/foaf/spec/#term_Document
SAZ: dc:document definition
CI: concerns about redefinition of other vocabularies properties
SAZ: it includes both "physical" and electronic
documents
... we can take away the term "electronic"
... my proposal is to improve the wording taking care of not redifining the
semantics
CV: why do we need the foaf:document?
... we can use Content classes
SAZ: Test Subject definitions are very generic
CV: the problem is the confusion between when to use Content and when to use Document
<shadi> PROPOSED RESOLUTION: (1) adopt wording FOAF about not distinguishing between physical and electronic documents, but highlighting the typical usage (2) respond to Diego that we do not agree that the definition of foaf:Document is too narrow (3) keep editor's note that ERT WG is still debating foaf:Document (4) continue assessing pros/cons of foaf:Document
<shadi> RESOLUTION: (1) adopt wording FOAF about not distinguishing between physical and electronic documents, but highlighting the typical usage (2) respond to Diego that we do not agree that the definition of foaf:Document is too narrow (3) keep editor's note that ERT WG is still debating foaf:Document (4) continue assessing pros/cons of foaf:Document
SAZ: adopt the dcmi-terms namespace
<shadi> RESOLUTION: adopt the DC namespace http://dublincore.org/documents/dcmi-terms/ in all specs
<cvelasco> Namespace: http://purl.org/dc/terms/
SAZ: need to recheck in all the specs
... have the same definitions for classes and instances
<shadi> RESOLUTION: rewrite the definition for OutcomeValue classes and instances to separate them semantically
SAZ: need to discuss more about the removal of the should requirements
<shadi> ACTION: shadi to look at ways for firming up the conformance section [recorded in http://www.w3.org/2009/06/03-er-minutes.html#action01]
<trackbot> Created ACTION-98 - Look at ways for firming up the conformance section [on Shadi Abou-Zahra - due 2009-06-10].
SAZ: suggestions for changes to the RDF representation has been checked with Iván
<shadi> RESOLUTION: adopt OWL constructors for all our specs
SAZ: he agrees is a good solution
<cvelasco> <owl:Ontology>
<shadi> RESOLUTION: point to the ontology documents from the HTML
<shadi> <link href="http://xmlns.com/foaf/spec/index.rdf" rel="alternate"
<shadi> type="application/rdf+xml" />
<shadi> ACTION: cvelasco to send another approach (OWL) for including the ontology documents in HTML [recorded in http://www.w3.org/2009/06/03-er-minutes.html#action02]
<trackbot> Created ACTION-99 - Send another approach (OWL) for including the ontology documents in HTML [on Carlos A. Velasco - due 2009-06-10].
<cvelasco> See http://www.w3.org/TR/swbp-vocab-pub/
SAZ: add a link to the RDF in the document
<shadi> [also add as an "alternate version" a link in the HTML to the RDF files]
<shadi> http://www.w3.org/2009/05/27-er-minutes#item01
SAZ: any comment on Pointers and Requirements?
no comments
SAZ: those documents are ready to go, please have a look at them
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2009May/0010
SAZ: SK, HTTP in RDF and Content in RDF priorities?
JK: the naming issues
<shadi> ContentInXML
<shadi> ContentAsXML
<shadi> http://www.w3.org/2009/05/20-er-minutes#item05
<shadi> ContentXML
<shadi> ExtensibleMarkupLanguageContent
<cvelasco> ... and adding "An"?
<shadi> DeclOfXML
MS: prefer the "as" option
CV: the problem is in the properties then
SAZ: do the name properties really need XML or are they more generic and well defined by the context?
<shadi> RESOLUTION: (1) most promising candidate for class names is ContentAsXML, ContentAsText, ContentAsBase64 (2) "LeadingMisc", "Rest", and "Standalone" do not need "XML" in the name (3) Johannes will start thread for XMLDecl and XMLEncoding
<shadi> next meeting: 10 June