W3C home > Mailing lists > Public > public-prov-wg@w3.org > April 2012

Re: PROV-ISSUE-222 (used-objectproperty): Datatype property for used? [Ontology]

From: Paul Groth <p.t.groth@vu.nl>
Date: Mon, 16 Apr 2012 21:59:59 +0200
Message-ID: <6CC193CD-A57B-4D1A-A2FD-29FEBE1CFA34@vu.nl>
CC: "public-prov-wg@w3.org" <public-prov-wg@w3.org>
To: Timothy Lebo <lebot@rpi.edu>
Absolutely :-)

On Apr 16, 2012, at 21:53, Timothy Lebo <lebot@rpi.edu> wrote:

> Thanks, Paul.
> 
> Will it go to http://www.w3.org/2011/prov/wiki/PROV_examples 
> 
> :-)
> 
> -Tim
> 
> On Apr 16, 2012, at 3:37 PM, Paul Groth wrote:
> 
>> Hi All 
>> 
>> Since I raised the issue, let me get an example up ... I think it will be a no brainer to solve just really need a good place to put application specific descriptions for example command line arguments.
>> 
>> Example coming tomorrow
>> 
>> Paul
>> 
>> 
>> On Apr 16, 2012, at 19:45, Timothy Lebo <lebot@rpi.edu> wrote:
>> 
>>> 
>>> On Apr 16, 2012, at 1:31 PM, Stephan Zednik wrote:
>>> 
>>>> 
>>>> On Apr 16, 2012, at 11:15 AM, Timothy Lebo wrote:
>>>> 
>>>>> 
>>>>> On Apr 16, 2012, at 11:44 AM, Stian Soiland-Reyes wrote:
>>>>> 
>>>>>> prov:value can specialize rdf:value ( and standards say so), but for is it would not really add any meaning beyond anything given by its domain (say prov:Entity).
>>>>>> 
>>>>> 
>>>>> I don't see the need to mirror it when rdf:value works just fine and already recognized by so many tools.
>>>> 
>>>> While rdf:value is recognized by tools, it has no defined meaning on its own (according to http://www.w3.org/TR/rdf-schema/#ch_value).
>>> 
>>> Thanks for pointing this out.
>>> "rdf:value is an instance of rdf:Property that may be used in describing structured values."
>>> is NOT how rdf:value has come to be used in the wild.
>>> 
>>> Funny that the example that they cite doesn't use rdf:value …. http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#example16
>>> 
>>> So then I'd propose we make prov:value a DatatypeProperty and provide a better definition than what the RDF spec provided.
>>> 
>>> 
>>>>  I also believe direct usage without restricting its type to owl:ObjectProperty or owl:DatatypeProperty also puts an ontology into OWL Full.
>>> 
>>> Another huge reason to define our own :-)
>>> 
>>>> 
>>>>> 
>>>>>> But we want string activities as well?
>>>>>> 
>>>>>> 
>>>>> 
>>>>> That's impossible. (and one says that, it means they should make an axiom…. prov:value rdfs:domain prov:Entity (which is disjoint with Activity))
>>>>> But worth it's weight of another property?
>>>> 
>>>> It seems to me we are conflating simple descriptions of activities and entities with the actual activity and entity resource.
>>> 
>>> I agree that this conflation is bad, but I can't say that I'm seeing it.
>>> Perhaps it's because there isn't an example on this issue yet.
>>> 
>>>> 
>>>> Why not just have an annotation that provides a human-readable description of the activity or entity?
>>>> 
>>>> To replace Activity/Entity individuals with string descriptions of said individuals would be a mistake.
>>> 
>>> +100
>>> 
>>> -Tim
>>> 
>>> 
>>>> 
>>>> --Stephan
>>>> 
>>>>> 
>>>>> 
>>>>>> We should be careful not to overlap rdfs:label...
>>>>>> 
>>>>>> 
>>>>> 
>>>>> Who proposed using rdfs:label?
>>>>> Agreed, this should be left out of the discussion.
>>>>> 
>>>>> -Tim
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Apr 16, 2012 4:36 PM, "Timothy Lebo" <lebot@rpi.edu> wrote:
>>>>>> 
>>>>>> On Apr 16, 2012, at 10:49 AM, Luc Moreau wrote:
>>>>>> 
>>>>>> > Hi Tim,
>>>>>> >
>>>>>> > Just a word to say that it's a problem that is not specific to the ontology.
>>>>>> > The problem is similar in other serializations.
>>>>>> > Should we have a statement about this in the dm?
>>>>>> 
>>>>>> That makes sense. Would you life to reserve prov:value?
>>>>>> PROV-O will not define prov:value in favor of rdf:value.
>>>>>> I think the rest of the PROV-O solution (content in RDF vocab) would fall outside of DM's control, as we've done before.
>>>>>> 
>>>>>> -Tim
>>>>>> 
>>>>>> > Luc
>>>>>> >
>>>>>> > On 04/16/2012 02:18 PM, Timothy Lebo wrote:
>>>>>> >> Paul (and Graham),
>>>>>> >>
>>>>>> >> The prov-o team discussed this last week and agreed that this topic is more appropriate in the best practices document.
>>>>>> >> We also outlined the recommended patterns.
>>>>>> >>
>>>>>> >> I put a stub entry at
>>>>>> >>
>>>>>> >> http://dvcs.w3.org/hg/prov/raw-file/1a7d883e143e/bestpractices/BestPractices.html#using-strings
>>>>>> >>
>>>>>> >> that says:
>>>>>> >>
>>>>>> >> * If you want to break RL and any tools built around PROV-O, just use a string.
>>>>>> >> * If you want to follow the datatype/objectproperty distinction, use a resource with rdf:value OR
>>>>>> >> * use content in rdf http://www.w3.org/TR/Content-in-RDF10/
>>>>>> >>
>>>>>> >> 1)
>>>>>> >> Can we move this issue to the best practices product?
>>>>>> >> http://www.w3.org/2011/prov/track/products/7
>>>>>> >>
>>>>>> >> 2)
>>>>>> >> Can you put a "string-heavy" example into http://www.w3.org/2011/prov/wiki/PROV_examples to motivate further development of the best practice?
>>>>>> >>
>>>>>> >> 3)
>>>>>> >> Can we close ISSUE-248  http://www.w3.org/2011/prov/track/issues/248 as a duplicate of this issue?
>>>>>> >>
>>>>>> >>
>>>>>> >> On Jan 19, 2012, at 4:36 AM, Graham Klyne wrote:
>>>>>> >>
>>>>>> >>
>>>>>> >>> Paul,
>>>>>> >>>
>>>>>> >>> This problem is, IMO, an atifact of the arguably arbitrary restrictions of description logic and OWL-DL.  If you don't need to be consrainted to OWL-DL then the problem does not arise.  Just saying.
>>>>>> >>>
>>>>>> >> The problem does arise practically, too. If the range of prov:used is a rdfs:Resource, then tools will handle it as such (and not a string).
>>>>>> >> So tools will choke while reading your account, even if they don't care about reasoning.
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>> Staying with the object/datatype property distinction, I think either of your suggested approaches can work, but I don't know about semantics of entity here - it seems to me that it should be possoible to formulate the semantics around two properties as well as one, even if the formulation is more complex.
>>>>>> >>>
>>>>>> >>
>>>>>> >>
>>>>>> >>> The second approach avoids the semantic uncertainties at the costof some added complexity in RDF representation.
>>>>>> >>>
>>>>>> >>
>>>>>> >> @Graham, could you elaborate this approach, so that we can articulate it in the best practices document?
>>>>>> >>
>>>>>> >> Thanks,
>>>>>> >> Tim
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>> I'm not sure this helps :(
>>>>>> >>>
>>>>>> >>> #g
>>>>>> >>> --
>>>>>> >>>
>>>>>> >>> On 18/01/2012 09:40, Provenance Working Group Issue Tracker wrote:
>>>>>> >>>
>>>>>> >>>> PROV-ISSUE-222 (used-objectproperty): Datatype property for used? [Ontology]
>>>>>> >>>>
>>>>>> >>>> http://www.w3.org/2011/prov/track/issues/222
>>>>>> >>>>
>>>>>> >>>> Raised by: Paul Groth
>>>>>> >>>> On product: Ontology
>>>>>> >>>>
>>>>>> >>>> Currently, prov-o:used is defined as an objectproperty. This is fine. However, we've be doing some modeling here at the VU where the parameter to a program is a string. Currently, this is not modelled using a prov-o:used edge but it seems like it should be. Is there anyway we can support this?
>>>>>> >>>>
>>>>>> >>>> My first inclination is to define a corresponding datatype property but this make break the semantics of entity...
>>>>>> >>>>
>>>>>> >>>> Another option might be to suggest using a blank node with the string attached using an application specific predicate.
>>>>>> >>>>
>>>>>> >>>> Suggestions?
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>> > --
>>>>>> > Professor Luc Moreau
>>>>>> > Electronics and Computer Science   tel:   +44 23 8059 4487
>>>>>> > University of Southampton          fax:   +44 23 8059 2865
>>>>>> > Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
>>>>>> > United Kingdom                      http://www.ecs.soton.ac.uk/~lavm
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
> 
Received on Monday, 16 April 2012 20:00:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:07:03 GMT