ERT WG -- 18 Oct 2006

test subjects is a local file

<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

johannesK: in rdf terms we need something really unique beside this label

<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.

ERT WG

18 Oct 2006

Attendees

Contents

test subjects is a local file

Summary of Action Items