- From: Graham Klyne <GK@ninebynine.org>
- Date: Fri, 26 Aug 2011 08:35:42 +0100
- To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- CC: public-prov-wg@w3.org
On 26/08/2011 00:19, Luc Moreau wrote: > > Hi Graham, > > Responses interleaved. > > On 25/08/11 14:48, Graham Klyne wrote: >> On 22/08/2011 23:30, Provenance Working Group Issue Tracker wrote: >>> >>> PROV-ISSUE-77 (paq-terminology): terminology issues [Accessing and Querying >>> Provenance] >>> >>> http://www.w3.org/2011/prov/track/issues/77 >>> >>> Raised by: Luc Moreau >>> On product: Accessing and Querying Provenance >>> >>> >>> Terminology is not always used consistently. Sometimes, it's confusing. I >>> group all these comments in a single issue. >>> >>> To start with, the word "context" which is overloaded. Furthermore, some >>> sentences have two occurrences of this word, one with the technical meaning, >>> one with the common sense meaning. In fact, we used to have a good term, >>> "subject of provenance", which we could consider here. >> >> This was discussed on the list when we moved away from "target", and so far >> the term "context" has found favour (and is also consistent with the usage >> associated with link relations). I'm not aware of any sentences in which the >> uses of context are contradictory: part of the value of this term is that it >> aligns pretty well with its colloquial meaning. (I didn't set out to write a >> formal document here, but one from which developers could create interoperable >> implementations.) > > I would like to see more support for the term context. If the WG supports it, so > be it. > Folks? > >> >>> Why do we have location_template and provenance_template? >>> Shouldn't they be provenance_location_template and provenance_content_template? >>> Both are indeed related to provenance. >> >> Indeed they are. I initially drafted the forms you mentioned, then decided >> against them. These names appear specifically in a description of a provenance >> service, so adding provenance- to the name isn't needed for disambiguation, >> and does make them more unwieldy. > > You seem to contradict yourself. provenance_template includes the word provenance. > I am arguing for consistency. Either both have it, or none has it. Well, I really don't care that much. "template" on its own would have seemed too bare to me. I'll change it back to the forms you suggest. (DONE in working copy) >>> The discovery service is sometimes referred to as discovery and retrieval >>> service. Shouldn't it be consistently referred as discovery and retrieval >>> service? But this is also referred to as provenance service. >> >> Yes, more consistency here would be nice, but I wonder if it comes at the >> expense of more clumsy text. Technically, it would be a discovery *and/or* >> retrieval service: either one or the other or both options can be provided. > > Alterantively, you could define a provenance service as having discovery and > retrieval capability, and use the term provenance service. OK, that could work. (Added note to rework text in working copy) >>> The text seems to make the distinction between resource-uri and context-uri. >>> But isn't it the case that a resource-uri is a context-uri? >> >> Not necessarily. resource-uri might be the dynamic resource, and context-uri >> might be a particular view of it (e.g. see recent discussion with Olaf about >> DBpedia Berlin page.) > Even if resource-uri denotes a dynamic resource, I would argue that it is also a > context-uri. Yes, I'd agree with that. But that doesn't preclude having different context URIs as well. > We are here exactly at the interface with the model. > I don't see why the dynamic resource denoted by http://www.bbc.co.uk/news/ > cannot be seen > as a PIDM entity (attributes with constant values are its initial launch date, > its owner, etc.) Yes I agree with that too, but there seem to be unresolved details we need to debate in the PIDM context. Once the dust settles there, I'd propose to review this terminology. #g --
Received on Friday, 26 August 2011 07:54:50 UTC