Re: prov-wg: Another name for Qualified?

Is too much for prov:?? to be prov:entity ...

Professor Luc Moreau
Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom

On 17 Feb 2012, at 22:57, "Timothy Lebo" <lebot@rpi.edu<mailto:lebot@rpi.edu>> wrote:

As an RDFer, the following doesn't look too bad.
Ontology-ers will hate it (which is ironic, since they should only be worried about the axioms and not the tokens).

:activity
    a prov:Activity;

    prov:used           :in;
    prov:usage [
       a prov:Usage;
       prov:?? :in;           # <--- Suggestions for this predicate very much welcome!
    ];

    prov:generated :out;
    prov:generation [
       a prov:Generation;
       prov:?? :out;
    ];
.

Short. And parallels even more nicely. I'm sold, Luc!


-Tim



On Feb 17, 2012, at 5:09 PM, Luc Moreau wrote:

Hi Paul,


s/Qualified// on properties too


hadQualifiedXXX -> hadXXX


And if you said s/had//
Then

hadQualifiedXXX -> XXX


Professor Luc Moreau
Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom

On 17 Feb 2012, at 21:51, "Paul Groth" <p.t.groth@vu.nl<mailto:p.t.groth@vu.nl>> wrote:

Hi Luc

I think we agree that Qualified shouldn't be in front of the class names. In the ontology they aren't.

The question is what the predicate should be between the activity and the Involvement subclass?

I'm open to suggestions.
Paul

On Feb 17, 2012, at 22:35, Luc Moreau <L.Moreau@ecs.soton.ac.uk<mailto:L.Moreau@ecs.soton.ac.uk>> wrote:

Hi Tim, Paul
Still in the spirit of simplification

used vs Usage
wasGeneratedBy vs Generation

Why do we need Qualified? If you say QualifiedGeneration, ...
I always expect a UnqualifiedGeneration ..  But there is no such class.

s/Qualified//

Luc


Professor Luc Moreau
Electronics and Computer Science
University of Southampton
Southampton SO17 1BJ
United Kingdom

On 17 Feb 2012, at 18:57, "Timothy Lebo" <lebot@rpi.edu<mailto:lebot@rpi.edu>> wrote:


On Feb 17, 2012, at 11:20 AM, Paul Groth wrote:

Hi Tim, Jim,

I like the suggestion a lot. [English teacher verification is good :-) ] Indeed, I was thinking that all the "had" in the ontology were a bit verbose. A blank node may indeed be the best way solve it for having long types.

Blank nodes should not be any way to solve URI length (or any other problem; they should be avoided at all costs).
Any occurrence of bnodes in my examples could  just as easily be URIs. I'm just using them for abbreviation to show the structure.

I'm not sure how you interpreted my example as using bnodes to solve a length problem. Could you explain?



A couple of questions in your examples:

- You have the prov:generated relationship but I don't see that in the ontology file although I do see it in the ProvRDF page? This is issue #98, which has no resolution http://www.w3.org/2011/prov/track/issues/98

Thanks for pointing that out. I agree with the issue and think that it should be added to the ontology as an owl:inverse of prov:wasGeneratedBy.
(oh, I created the issue. Glad that I still agree with it!)
Though, I'm expecting push back on an inverse being added to the ontology.


- You use the relation prov:entity and not prov:hadQualifiedEntity.

prov:entity was the initial stand in. And I'm bringing it up again because it's a "whole lot shorter".


This also isn't in the ontology or this a suggestion?

resurrected suggestion.


---
I'm trying to think of other shorter names that convey the same meaning as qualified involvement.

For the class or predicates? For the class, go "Involvement". Short.
For the predicate, "qualifiedGeneration / Use" is worth the length in my opinion, because it parallels prov:generated / prov:used in a natural way.

-Tim


Just for less typing but clearly I don't want to open a huge debate there.

If anyone, comes up with suggestions that would be great. I'll try to think of some myself. But again this may be too picky

thanks for the quick response,
Paul

Jim McCusker wrote:
To be clear, we're using "qualified" as a verb, not a noun, which is why
we can drop "had".

Jim

On Feb 17, 2012 8:50 AM, "Timothy Lebo" <lebot@rpi.edu<mailto:lebot@rpi.edu>
<mailto:lebot@rpi.edu>> wrote:

1)
Although it doesn't shorten it up much, I think it is _much_ clearer
if we drop "had".

prov:hadQualifiedGeneration -> prov:qualifiedGeneration

This changes the statement from a passive to active, which will make
all of my writing teachers happy.
The Activity qualified its Generation.

This also parallels the unqualified form nicely ("generated" and
"qualifiedGeneration") -- a fork in the road with two routes that a
client can follow, depending on how much detail they want.:

:my_activity
a prov:Activity;
prov:generated :my_entity;
prov:qualifiedGeneration [
a prov:Generation;
prov:entity :my_entity;
:foo :bar;
]
.


2)
QualifiedInvolvement -> Involvement still makes _complete_ sense,
since it is inherently qualifying the binary relation. Being an
Involvement _means_ that you're being pointed at with some
subproperty of prov:qualifiedInvolvement (e.g. qualifiedGeneration)
AND you're pointing to the (rdf:object) involvee with, say, prov:entity.

As for the predicates hanging off of the Involvement, we started
with just:

:my_activity prov:qualifiedGeneration [
a prov:Generation;
prov:entity :my_entity;
]

but we run into a slight hiccup when we're qualifying the
Involvement between two Entities b/c we don't know which is the
rdf:subject and which is the rdf:object of the binary relation we're
qualifying. However, these situations start to leave core, and a
qualified involvement between two entities should be some Activity,
so we can avoid the degenerate Entity-Entity case.

-Tim



On Feb 16, 2012, at 8:53 AM, Paul Groth wrote:

Hi All,

The idea behind QualifiedInvolvement is great and it's been
resolved for a while so I don't want to open it up.

but.... could we get a better name?

The name is long, especially for the properties. So you have to
write:

ex:activity1 prov:hadQualifiedGeneration ex:g1.
ex:g1 prov:hadQualifiedEntity ex:e1.
ex:g1 prov:wasGeneratedAt [owlTime:inXSDDateTime
2006-01-01T10:30:00-5:00].

could we shorten them up somehow? Any suggestions?

regards,
Paul