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

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

From: Stephan Zednik <zednis@rpi.edu>
Date: Mon, 16 Apr 2012 11:31:13 -0600
Cc: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>, public-prov-wg@w3.org, Luc Moreau <l.moreau@ecs.soton.ac.uk>
Message-Id: <E4E109AB-3311-41A6-91E9-86B6D6F81A11@rpi.edu>
To: Timothy Lebo <lebot@rpi.edu>

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).  I also believe direct usage without restricting its type to owl:ObjectProperty or owl:DatatypeProperty also puts an ontology into OWL Full.

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

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.

--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 17:32:45 GMT

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