Re: PROV-ISSUE-77 (paq-terminology): terminology issues [Accessing and Querying Provenance]

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.

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

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

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


>
>> Provenance resource is also mentioned. Is this provenance information?
>
> Roughly, yes,  But if we get to be really nit-picky, provenance 
> information is what one gets when retrieving a provenance resource.
>
>> Can we have a better name than provenance-location-uri? First, 
>> shouldn't we say provenance-locations-uri?  this would allow us to 
>> see that several locations are permitted (whereas we have a singe 
>> provenance information template). Is location the right term? why not 
>> set provenance-uri?
>
> OK, first suggestion done.
>
> I think provenance-locations-URI is right as it denotes a resource 
> containing one or more provenance locations.  I suppose we might say 
> provenance-URIs-URI, but I think that begs more confusion than it 
> clears up.
>

Luc

> #g
> -- 
>

Received on Thursday, 25 August 2011 23:19:48 UTC