See also: IRC log
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2006Oct/0000
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2006Oct/0011
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2006Oct/0031
saz: two issues, first one about content
file
... second about security/privacy
cv: seems that two things are mixed up here
saz: lets go through issues one by one
... one approach: if you do not want to share the files, do not share the
report
cv: where is really the problem?
saz: what do others think?
<CarlosI> c:/documents..../user name/...
carlosI: its not that simple. there are a lot of privacy related questions, e.g. paths in windows systems
cv: its the decision of the people if they want to share or not
saz: lets discuss e.g. password encryption - should that be an issue in EARL1.0?
cv: not, it is not an issue:
CarlosI: it could be.
... if we want a third party validation we have to provide password
information
... that information could be encrypted in order to have no problems
... proposal is to have another property for encrypted information as
password
saz: password would be part of HTTP request
cv: we often get username and password from
customers, but we do not put into any report.
... If you do not want to share something, do not put it
carlosI: if you want to share, how can you do with some security?
cv: can encrypt everything, but we are getting into very dangerous field
saz: maybe you want to show some results, but
not username and password...
... do we want to go there?
<Daniela2> chrisr: agrees that we do not have to put secure things into report
saz: I can see the point from carlosI.
johannesk: agree with many who spoke before.
... one additional thought: we are talking about an rdf model
... perhaps split the model into confidential part and non confidential
part
saz: thats a good point
... do we want to clearly say in the scope section that security is out of
scope of earl?
cv: why should we do that?
saz: even in the guide? couldnt it be helpful?
cv: I do not think so. It could apply to anything on the web...
saz: carlosI, are you convinced?
carlosI: not really, but can live with it.
... use case: you have a group of people that does validations for websited.
there are people from different fields (managers, technicians). all these
people share repository in EARL about results. technical people need
passwords. if they could be included in report (encrypted), it would be
easier.
saz: the process "encrypt" is the same as "publish seperately"
<CarlosI> earl:password_encrypted
cv: what carlosI proposes is workflow issue and not a language issue
carlosI: no, its about providing enough power to the language to save work
cv: it's a different approach.
saz: it's an issue worth thinking about.
<scribe> ACTION: CarlosI will summarize his arguments to be discussed with others in next call. [recorded in http://www.w3.org/2006/10/18-er-minutes.html#action01]
saz: back again to local files. assuming we
have a solution for confidentiality
... the local file is different from web content.
... the definition of web content is more than having a resource available on
an http protocol
... file content is different - it is on a local harddisk
... providing a uri for a file name does not make it unique, e.g. dynamic ip,
same name for two computers
... we talked about a property called 'file name'. its not unique, just a
handle
... also talked about a way to store the content of the file
... do we need to worry about uniqueness?
cv: dicussion about uniqueness is not
relevant.
... if you want to share a file, make it available for everyone.
carlosI: use case: customers gives files for evaluation, do this validation locally on a computer, want to save this information in earl format.
johannesK: what you really need is an uri.
carlosI: what is the approach regarding the property for web content uri or just rdf staff?
saz: yes, there was a resolution on previous call: we will use rdf:about
carlosI: if we have this resolution, we should use the same approach for file content
saz: why?
carlosI: just to be consistent
saz: we have property such as a file name which
is a handle
... web content has uri
cv: the filename is meaningless. we need the whole file.
saz: file content class can use rdf:about or
rdf:id
... within the file content class there is a file name property and a
source
cv: has there already been the decision to use file content class?
saz: no formal decision, renaming web content
was one option
... have to check if there is enough support for file content class
<shadi> http://www.w3.org/2006/10/04-er-minutes
johannesK: file name would just be a label, wouldn't it?
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2006Oct/0011.html
carlosI: yes, what we really need something that is unique
<shadi> <earl:FileContent rdf:ID="unique123">
<shadi> <dc:date rdf:datatype="&xmls;Date">2005-06-25</dc:date>
<shadi> <earl:filename>file.html</earl:filename>
<shadi> <earl:filesource><![CDATA[aksgbq3833o3gbo4zgblakc8t9ut2]]></earl:filesource>
<shadi> </earl:FileContent>
johannesK: in rdf terms we need something really unique beside this label
<shadi> <earl:FileContent rdf:about="file://...">
<shadi> <dc:date rdf:datatype="&xmls;Date">2005-06-25</dc:date>
<shadi> <earl:filename>file.html</earl:filename>
<shadi> <earl:filesource><![CDATA[aksgbq3833o3gbo4zgblakc8t9ut2]]></earl:filesource>
<shadi> </earl:FileContent>
<JohannesK> Daniela2: no, in RDF we do have a unique thing, but Carlos wants another unique thing
saz: two ways of describing file content (see example)
johannesK: must be unique within the model - thats not the case for file content
carlosI: what about changing resources on the web?
saz: let's continue discussion at next telecon.