See also: IRC log
JK: may be able to use "test subject" class otherwise can use "file content" class.
SAZ: recalls Charles saying we could use "test subject" class which is well formed URI but is not unique
SAZ: could give "test subject" a unique ID
JK: can use IP number instead of "file:..." if IP is static
SAZ: although may not have an IP number at all
... is it important to store content of file?
JK: yes, especially if file is not public
... file content needs to go into report if file is not public
SAZ: proposal is to change "http body" in this content
JK: but "http body" does not have a domain yet and could be used anywhere if we change comment
SA: not good to change vocabulary because it should be stand alone
JK: we could create the propery in a namespace
(e.g. "content") and extent "http body" property so "http body" is derived
... the benefit is that we have "http body" property in proper vocabulary
SAZ: We have property to store URI and can put filename in there. But what are our needs?
JK: In RDF we need unique identifier for
resource but not for property and we need that and to be unique.
... Filename is a label for stored content.
... We need something for storing non-public content.
... We could use something like "body" property from HTTP. Could use as-is and then change describing stuff or could create another property and extend it.
... Could use in "test subject" but what to do when we test source code in various forms?
... May not need "file content" class.
SAZ: Wonders what are disadvantages of creating "file content" class??
<JohannesK> http:body rdfs:subPropertyOf foo:base64Content
<JohannesK> TestSubject has property foo:base64Content
SAZ: If "file content" class we can recommend using properties like "file name" etc.
<shadi> earl:filesource rdfs:subPropertyOf foo:base64Content
<shadi> ...in earl:FileContent classes
SAZ: Can still use generic properties and still
use specific sub-properties.
... Thinks that "file content" class has it's own uses.
... If no other comments will leave for now as we're a small group today.
... No hearing strong feelings for or against proposal so let stew.
JK: Could use "node" property in RDF.
SAZ: We could still propose to use it our way.
JK: uri:uri is part of HTTP request so if not there as property then somethink is missing.
SAZ: It's still there - as part of HTTP request although request is optional. So we have additional uri:uri property.
JK: I'm OK with just using RDF: about.
<shadi> "Term for URI"
JK and SAZ: Do not need uri:uri because we can use rdf: about.
<shadi> earl:filename rdfs:subPropertyOf uri:uri
SAZ: Everyone agree we don't need uri:uri in property class?
<davidr> far more intuitive
resolution: Drop uri:uri in webcontent class.
SAZ: Extensibility section not relavent to schema. Should be in EARL guide, not in schema.
Resolution: Move extensibility section from schema to EARL guide.
SAZ: RDF itself does not have it inside the doc but others (like FOAF) do have it inside.
JK: But they don't include the RDF schema in
... Don't have strong feelings but can be seperate or include in spec itself.
SAZ: This doc will be a "note" not a
... Asks that everyone read it.