Previous and following versions

[Paolo Ciccarese]

Stian stated:

"We should consider as Andy says if we also need a property to link to
"all possible" versions. Kind of like pav:otherVersions?"

I am good with that, but I would also consider to better represent previous and following versions.

I would consider something like:

V3 pav:previousVersion (functional) V2

V2 pav:previousVersion V1

and

V3 pav:earlierVersion (not sure about the name) v2,v1

In paraller pav:followingVersion and pav:laterVersion.

Basically I am proposing the pattern we implemented in Collections Ontology:
co:hasNextItem (functional)
http://www.essepuntato.it/lode/owlapi/http://purl.org/co/#d4e317

co:isFollowedBy (transitive)
http://www.essepuntato.it/lode/owlapi/http://purl.org/co/#d4e170

[Stian Soiland-Reyes]

On Wednesday, 16 October 2013 15:56:42 UTC+1, Paolo Ciccarese wrote: 

"We should consider as Andy says if we also need a property to link to
"all possible" versions. Kind of like pav:otherVersions?" 

I am good with that, but I would also consider to better represent previous and following versions.

I would consider something like:

V3 pav:previousVersion (functional) V2

V2 pav:previousVersion V1

and

V3 pav:earlierVersion (not sure about the name) v2,v1

(I guess from this pav:previousVersion is subproperty of pav:earlierVersion then, as the previous is necessarily earlier)

OK, so in this case you enforce a linearity, v1 and v2 are somehow 'older' than v3. Would this still be applicable to Andy's hierarchical example?

Or would it be possibly sufficiently modelled by going one level down from the current version, and then to any earlier version from there?

<http://example.com> pav:currentVersion <http://example.com/v4> .

<http://example.com/v4> pav:previousVersion <http://example.com/v3> ;

         pav:earlierVersion <http://example.com/v3>, # implied

               <http://example.com/v2>, <http://example.com/v1> .

<http://example.com/v3> pav:previousVersion <http://example.com/v2> ;

  pav:earlierVersion <http://example.com/v2>, # implied

           <http://example.com/v1> .

It is a lot of repetition... Using Andy's hierarchy would avoid the repetition, all the versions would simply be one of the versions of the 'unversioned master' - this could be a bnode if you just want to group together all the versions.

 

In paraller pav:followingVersion and pav:laterVersion.

Not so sure about the need for those, that would generally just be a repetition in the opposite direction, we don't have those kind of inverse properties (except for pav:curates which I believe we deprecated).  

 

Basically I am proposing the pattern we implemented in Collections Ontology:
co:hasNextItem (functional)
http://www.essepuntato.it/lode/owlapi/http://purl.org/co/#d4e317

co:isFollowedBy (transitive)
http://www.essepuntato.it/lode/owlapi/http://purl.org/co/#d4e170

I think in general that can be a good pattern. But it would be good to avoid having 3-4 different ways to express the version tree.. 

[Paolo Ciccarese]

On Wed, Oct 16, 2013 at 11:34 AM, Stian Soiland-Reyes <st...@mygrid.org.uk> wrote:

On Wednesday, 16 October 2013 15:56:42 UTC+1, Paolo Ciccarese wrote: 

"We should consider as Andy says if we also need a property to link to
"all possible" versions. Kind of like pav:otherVersions?" 

I am good with that, but I would also consider to better represent previous and following versions.

I would consider something like:

V3 pav:previousVersion (functional) V2

V2 pav:previousVersion V1

and

V3 pav:earlierVersion (not sure about the name) v2,v1

(I guess from this pav:previousVersion is subproperty of pav:earlierVersion then, as the previous is necessarily earlier)

Mimicking CO: pav:previousVersion (functional) has super property pav:rearlierVersion (transitive)

 

OK, so in this case you enforce a linearity, v1 and v2 are somehow 'older' than v3. Would this still be applicable to Andy's hierarchical example?

Or would it be possibly sufficiently modelled by going one level down from the current version, and then to any earlier version from there?

<http://example.com> pav:currentVersion <http://example.com/v4> .

<http://example.com/v4> pav:previousVersion <http://example.com/v3> ;

         pav:earlierVersion <http://example.com/v3>, # implied

               <http://example.com/v2>, <http://example.com/v1> .

<http://example.com/v3> pav:previousVersion <http://example.com/v2> ;

  pav:earlierVersion <http://example.com/v2>, # implied

           <http://example.com/v1> .

It is a lot of repetition... Using Andy's hierarchy would avoid the repetition, all the versions would simply be one of the versions of the 'unversioned master' - this could be a bnode if you just want to group together all the versions.

I would just say:

<http://example.com> pav:currentVersion <http://example.com/v4> .
<http://example.com/v4> pav:previousVersion <http://example.com/v3> ;

<http://example.com/v3> pav:previousVersion <http://example.com/v2> ;

I think the rest can be inferred.

 

 

In paraller pav:followingVersion and pav:laterVersion.

Not so sure about the need for those, that would generally just be a repetition in the opposite direction, we don't have those kind of inverse properties (except for pav:curates which I believe we deprecated).  

This can help for other kinds of inferences... including understanding what is the latest version.

But it is not necessary I guess.

 

 

Basically I am proposing the pattern we implemented in Collections Ontology:
co:hasNextItem (functional)
http://www.essepuntato.it/lode/owlapi/http://purl.org/co/#d4e317

co:isFollowedBy (transitive)
http://www.essepuntato.it/lode/owlapi/http://purl.org/co/#d4e170

I think in general that can be a good pattern. But it would be good to avoid having 3-4 different ways to express the version tree.. 

No I was proposing something back-compatible, all I say is:

<http://example.com/v4> pav:previousVersion <http://example.com/v3> ;

That becomes (because of inference):

<http://example.com/v4> pav:previousVersion <http://example.com/v3> ;

         pav:earlierVersion <http://example.com/v3>,

               <http://example.com/v2>, <http://example.com/v1> .

And of course we can still keep the pointer to the latest version.

<http://example.com> pav:currentVersion <http://example.com/v4> .

 

Or there is a mistake in my thinking?

[Stian Soiland-Reyes]

No, your reasoning is perfect, now I get why you meant the same as in
CO ontology.

So really you only need to state previousVersion, but do so for each
version, then you can do standard OWL reasoning, and find any earlier
versions expressed using pav:earlierVersion (of course not necessarily
in time-order).

If all the intermediate previousVersion's are not stated, or just want
to point to a particular earlierVersion directly for some reason, then
you can still be explicit.


If we wanted to, we could also introduce a symmetric transitive
superproperty pav:otherVersion (super prov:alternateOf), which can
also be superproperty of pav:currentVersion. Now you can get all
versions by using pav:otherVersion.

(No need for property chains then to get through pav:currentVersion,
although that would be another option).

This is all very beautiful OWL. However, this is also quite
heavyweight OWL (does it mean OWL Full profile or just DL?), counter
to the current vocabulary style of PAV - it could easily put many
people off. So if we went through with this I would want to keep this
in a separate OWL ontology, say http://purl.org/pav/owlfull


I would like to hear if EBI would be happy with such an approach.. then from:

<http://example.com/> pav:currentVersion <http://example.com/v5> .
<http://example.com/v5> pav:previousVersion <http://example.com/v4> .
<http://example.com/v4> pav:previousVersion <http://example.com/v3> .
<http://example.com/v3> pav:previousVersion <http://example.com/v2> .
<http://example.com/v2> pav:previousVersion <http://example.com/v1> .

You could use regular OWL reasoning to get (amongst others):

<http://example.com/> pav:otherVersion <http://example.com/v3> .
(/ other v5 other v4 other v3) )

<http://example.com/v3> pav:earlierVersion <http://example.com/v1> .
(v3 earlier v2 earlier v1)

<http://example.com/v1> pav:otherVersion <http://example.com/v5> .
(because of symmetry of otherVersion - and so I would argue
pav:laterVersion is not really needed).

--
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/0000-0001-9842-9718

[Simon Jupp]

Wouldn't this also get entailed? Not sure we want that. 

<http://example.com/v1> pav:otherVersion <http://example.com/> .

What if we had

Asserted:

ex currentVersion ex1

ex1 previousVersion ex2

ex2 previousVersion ex3

earlierVersion is transitive

previousVersion subPropertyOf earlierVersion

role chain: currentVersion o previousVersion -> earlierVersion

Then in OWL DL we can infer

ex earlierVersion ex2, ex3

ex1 earlierVersion ex3

ex2 earlierVersion ex3

Which is close what we want.

[Paolo Ciccarese]

That would be OWL DL. CO is OWL DL. In principle I don't want people to 'need' inference. But if we define things properly and we allow for it is a plus.

--
Dr. Paolo Ciccarese
http://www.paolociccarese.info/
Biomedical Informatics Research & Development
Instructor of Neurology at Harvard Medical School
Assistant in Neuroscience at Mass General Hospital
Member of the MGH Biomedical Informatics Core
+1-857-366-1524 (mobile)   +1-617-768-8744 (office)

CONFIDENTIALITY NOTICE: This message is intended only for the addressee(s), may contain information that is considered
to be sensitive or confidential and may not be forwarded or disclosed to any other party without the permission of the sender.
If you have received this message in error, please notify the sender immediately.

[essepuntato]

Dear all,

I'm Silvio Peroni, and I was invited in this group by Paolo to discuss a bit about the proposal for the CO-like pattern to handle versions.

First of all, sorry to be so late in answering you, it had been a quite complex week end, indeed.

I quite agree on Paolo's proposal of using the approach of pav:earlierVersion and pav:previousVersion to handle the scenario. However I'm a bit worried about specifying the pav:previousVersion as functional. Let me expand on this.

In CO, we have nextItem and previousItem (both functional), which are sub-properties of followedBy and precededBy (both transitive) respectively. The specification of the functional characteristic on such properties is, in my opinion, mandatory in CO, since in lists we want to be sure that an item can have only one other item following (and preceding) it directly.

However, when we speak about versioning, I think we should adopt a more general approach, as suggested by the real, implicit, pattern from which CO is based, i.e. the sequence pattern [1]. Here the "directFollows" and "directPrecedes" properties are not defined as functional, since the pattern allows one to say that an entity (what ever it is) can be produced as result of one or more other entities.

This is particularly true for softwares, when, for instance, a particular program P1 is forked in two different branches P1_b1 and P1_b2, developed independently by two different groups of programmers, and then merged in another new version P2 that results by using what was developed in both P1_b1 and P1_b2. I think that a similar scenario can be applied also to ontology development processes, of course.

Using PAV, or, better, Paolo's proposal for versioning, it can be modelled as follows:

P2 pav:previousVersion P1_b1, P1_b2 .

P1_b1 pav:previousVersion P1 .

P1_b2 pav:previousVersion P1 .

If we keep the functional characteristic in pav:previousVersion, we will infer that P1_b1 and P1_b2 are actually the same version, while it is clearly not true.

Thus, my suggestion is simply to remove that constraint, leaving free to specify whatever (and any number of) previous version one must specify.

OK, I think that's all. Sorry for the verboseness...

S.

[1] - Sequence pattern: http://ontologydesignpatterns.org/cp/owl/sequence.owl

[Stian Soiland-Reyes]

I agree, we'll not define pav:previousVersion to be an
owl:FunctionalProperty for that reason - but rather keep the current
wording as we have on other properties:

> This property is normally used in a functional way, although PAV does not formally restrict this.

> --
> You received this message because you are subscribed to the Google Groups
> "PAV ontology: Provenance, Authoring and Versioning" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pav-ontology...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Stian Soiland-Reyes]

Hm, but with that you have enforced that ex has "earlier" version ex2
and ex3 - I think you better decide if ex:currentVersion is an
hierarchical or linear relationship!

Perhaps this is a good point to show the PROV view on specialization
(its hierarchical way of describing things):

http://www.w3.org/TR/prov-primer/#alternate-entities-and-specialization
http://www.w3.org/TR/prov-primer/#alternate-entities-and-specialization-1
http://www.w3.org/TR/prov-dm/#component5

> Example:
> The BBC news home page on 2012-03-23 ex:bbcNews2012-03-23 is a specialization of the BBC news page in general bbc:news/.
> This can be expressed as follows.
> specializationOf(ex:bbcNews2012-03-23, bbc:news/)


I would say that pav:currentVersion should very much be a subproperty
of prov:generalizationOf - the inverse of pav:specializationOf. Then I
don't think it would be right to say that this general over-all-entity
has an 'earlier' version of the individual older versions, because
those older versions are also specializationOf the over-all entity -
just like the BBC homepage yesterday and BBC homepage today are both
specialization of the BBC homepage.

However, having a property chain to define that common
prov:specializationOf would be useful.


If earlierVersion is subproperty of otherVersion, then ex would still
have otherVersion ex2. But perhaps you are proposing to not have
that common superproperty?

"otherVersion" alone without an "earlierVersion" (or its inverse)
means that the versions are related in some non-linear fashion.
currentVersion is one such (sub)relation. The implied inverse would be
"isCurrentVersionOf" or something - which certainly is also a kind of
"otherVersion"?

> --
> You received this message because you are subscribed to the Google Groups
> "PAV ontology: Provenance, Authoring and Versioning" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pav-ontology...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Simon Jupp]

Stian,
Sorry, earlierVersion was a bad label to choose, it should have been something like versionEarlierThanCurrent :). Anyway, given what you have said, I don't think we really need to capture that level of detail anyway. We just want to link all versions from the abstract, which I guess we can do with either dct:hasVersion or prov:isGeneralizationOf. However, given that pav are defining hasCurrentVersion for us, would it not also make sense for pav to provide a pav:isVersionOf/pav:hasVersion super property?

Then we would do something like

>> ex pav:hasCurrentVersion ex1
>> ex pav:hasVersion ex1
>> ex pav:hasVersion ex2

>> ex1 pav:previousVersion ex2
>> ex1 pav:isVersionOf ex
>> ex2 pav:isVersionOf ex

[Alasdair Gray]

Hi

Did we come to a resolution on this idea?

The HCLS group would like to use the pav:isVersionOf property as a means to link a versioned description to the abstract description of the dataset.

Alasdair

On Wednesday, 16 October 2013 15:56:42 UTC+1, Paolo Ciccarese wrote:

[Stian Soiland-Reyes]

I just need Simon to clarify which terms he agreed on needing, but I think we could include the pav:isVersionOf as specialization of the dct isVersionOf.

I'll make a branch and draft some descriptions next week and check back here and with hcls. Ping me if I forget! :)

--

[Stian Soiland-Reyes]

I am a bit torn between the inverses pav:isVersionOf and
pav:hasVersion. I don't want to define both in PAV as you would not
know which one is used where, and not everyone does OWL reasoning. I
have gone for hasVersion for now as the use-case was more to say
'which versions exists of this thing' rather than 'what is the more
mythical abstract view of this thing' - and also makes
pav:hasCurrentVersion fit in. The sad thing is that PROV goes
backwards in time, so I had to introduce the lesser-known inverse
prov:generalizationOf.



I have drafted some changes in the experimental OWL:

http://pav-ontology.googlecode.com/svn/branches/2.3/pav.owl


For details, see the new properties pav:hasVersion,
pav:hasCurrentVersion and pav:hasEarlierVersion:

http://www.essepuntato.it/lode/http://pav-ontology.googlecode.com/svn/branches/2.3/pav.owl#http://purl.org/pav/hasVersion

http://www.essepuntato.it/lode/http://pav-ontology.googlecode.com/svn/branches/2.3/pav.owl#http://purl.org/pav/hasCurrentVersion

http://www.essepuntato.it/lode/http://pav-ontology.googlecode.com/svn/branches/2.3/pav.owl#http://purl.org/pav/hasEarlierVersion


I have also copied into the OWL the relevant bits of:

prov:alternateOf
prov:specializationOf (and its inverse prov:generalizationOf)
dct:hasVersion
dct:isVersionOf (superproperty of prov:wasRevisionOf from prov-dc)


And updated descriptions in:

pav:previousVersion



As you can see I have hardened pav:hasVersion quite a bit from the
loose dct:hasVersion - our hasVersion requires some kind of snapshot
of more a permalink-like nature. hasCurrentVersion requires a loose
'content equivalence' snapshot - it is implied that hasVersion are
similar snapshots from earlier in time, but I didn't want to force in
the time-concept for those.


For Alasdair's usecase I am not sure if this new pav:hasVersion would
be appropriate, because the abstract description of the dataset does
not have the same "content" as the versioned dataset, does it?
Alasdair, could you describe a bit more what is the concept of the
abstract dataset?


My biggest fear now is for people who don't read descriptions. They
will just see the terms:

pav:hasVersion
pav:hasEarlierVersion
pav:hasCurrentVersion
pav:previousVersion

.. and conclude that they could do (all wrong according to my draft):

<http://example.com/> pav:previousVersion <http://example.com/2012-12-15>.

<http://example.com/2012-12-15> pav:hasCurrentVersion <http://example.com/> .

<http://example.com/2012-12-15> pav:hasVersion
<http://example.com/2012-12-15?withbellsandwhistles>

(and complain that dct:hasVersion does the same)

and even:

<http://example.com/document> pav:hasVersion
<http://example.com/changelog/2012-12-15>

e.g. thinking of a Version as some freestanding Milestone Marker that
looks nothing like the unversioned Document.


On 6 December 2013 22:44, Stian Soiland-Reyes

[Alasdair Gray]

Hi

Sorry missed this email and am just following up on the issue again.

So we have two overlapping but distinctly different use cases that we are trying to satisfy. Both are related to an abstract, time unchanging, representation of a dataset and its relationship to specific versions of that dataset, e.g. the notion that there is a ChEMBL dataset and that it now has 17 distinct versions. The differences come from whether it is the publisher making the metadata available or the data is being represented in a registry service. 

In the publisher use case (EBI), they want an abstract resource that can point to every versioned resource (pav:hasVersion). They also want to distinguish one resource as the current one (pav:hasCurrentVersion) and are willing to take on the maintenance burden of updating that link every time a new version is published.

In the registry use case (coming from the HCLS), they again want an abstract resource related to the version resources, but do not want a maintenance burden on the abstract resource. Thus they require a pav:isVersionOf property to go from the versioned to the unversioned. This would also satisfy the EBI case. In this case, there is no desire to have a pav:hasCurrentVersion as this would incur a maintenance headache.

Stian, I've had a quick look at the text you drafted for the descriptions. One thing to note is that the versioned representation is not equivalent to the unversioned. While they both refer to the same abstract dataset, the versioned one is more specific and has properties that do not hold for the unversioned representation.

Alasdair

[Stian Soiland-Reyes]

Thanks for a good summary of the use cases.


Although the HCLS use case will not want to maintain the
pav:hasCurrentVersion, there is no such requirement. Stating
pav:hasVersion is not saying that the object is not the current
version (indeed, hasCurrentVersion is a subproperty of hasVersion).


I am not sure why we should need to add an inverse property in this
case, as you would still need to come up with some URI for the
abstract resource. Why can't the registry still say:

<http://example.com/theAbstract> pav:hasVersion
<http://example.com/specificVersion2> .


The reason I am reluctant to add the inverse is that as a
"lightweight" ontology we have avoided inverse properties (except for
pav:curates which has been deprecated), and this change we are
discussing here is adding



I think I will have to modify the text for 'equivalent', I agree that
the more specific one would obviously be able to have more specific
properties that don't apply to the unversioned. (that is actually the
interpretation from prov:specializaionOf anyway).

Perhaps I should loosen the language about "unversioned"? I was
preparing a blog post and realized that the hierarchy of hasVersion
could in theory also be used to model different granularities of
versions, e.g. with major/minor/patch:


PAV
hasVersions:

PAV 1 PAV 2

hasVersions:

PAV 1.2 PAV 2.0 PAV 2.1 PAV 2.2


2.1 hasVersions:

PAV 2.1.0 2.1.1 2.1.2




Simon, do you have any further comments on this as we take it forward?
You said you were thinking of deploying datasets with pav:*Version
properties. If I am to release this ontology change before Christmas
we're quickly running out of time..

As a reminder, the suggested modified ontology is documented here:

http://www.essepuntato.it/lode/http://pav-ontology.googlecode.com/svn/branches/2.3/pav.owl#http://purl.org/pav/hasVersion

[Simon Jupp]

Stian,
I agree that "equivalent content" is not appropriate, but otherwise I think it all looks good.
We are holding back the release of the new dataset description until after the holidays, so don't worry about that.
Cheers
Simon

[Stian Soiland-Reyes]

I don't quite understand.. anyone can claim pav:hasVersion just like
pav:isVersionOf?

On 17 December 2013 10:34, Alasdair J G Gray <Alasda...@gmail.com> wrote:
>
> On 17 Dec 2013, at 10:19, Stian Soiland-Reyes

> <soilan...@cs.manchester.ac.uk> wrote:
>
> Thanks for a good summary of the use cases.
>
>
> Although the HCLS use case will not want to maintain the
> pav:hasCurrentVersion, there is no such requirement. Stating
> pav:hasVersion is not saying that the object is not the current
> version (indeed, hasCurrentVersion is a subproperty of hasVersion).
>

> Indeed that is correct. You could probably traverse the previousVersion
> links to discovery which is the latest that is known about.

>
>
> I am not sure why we should need to add an inverse property in this
> case, as you would still need to come up with some URI for the
> abstract resource. Why can't the registry still say:
>
> <http://example.com/theAbstract> pav:hasVersion
> <http://example.com/specificVersion2> .
>

> The problem is that the publisher of the data only has control of their copy
> of the abstract description. The description could also be stored in an
> external registry such as MIRIAM. That is why we favour the isVersionOf form
> of the predicate.

>
>
> The reason I am reluctant to add the inverse is that as a
> "lightweight" ontology we have avoided inverse properties (except for
> pav:curates which has been deprecated), and this change we are
> discussing here is adding
>
>
>
> I think I will have to modify the text for 'equivalent', I agree that
> the more specific one would obviously be able to have more specific
> properties that don't apply to the unversioned. (that is actually the
> interpretation from prov:specializaionOf anyway).
>
> Perhaps I should loosen the language about "unversioned"? I was
> preparing a blog post and realized that the hierarchy of hasVersion
> could in theory also be used to model different granularities of
> versions, e.g. with major/minor/patch:
>
>
> PAV
> hasVersions:
>
> PAV 1 PAV 2
>
> hasVersions:
>
> PAV 1.2 PAV 2.0 PAV 2.1 PAV 2.2
>
>
> 2.1 hasVersions:
>
> PAV 2.1.0 2.1.1 2.1.2
>
>

> Yes, that is exactly the sort of hierarchy that we are trying to support.
>
> Alasdair

> Dr Alasdair J G Gray
> Research Associate
> Alasda...@manchester.ac.uk
>
> http://www.cs.man.ac.uk/~graya/
>
> Please consider the environment before printing this email.
>
>
> ________________________________
>
> Sunday Times Scottish University of the Year 2011-2013
> Top in the UK for student experience
> Fourth university in the UK and top in Scotland (National Student Survey
> 2012)
>
> We invite research leaders and ambitious early career researchers to join us
> in leading and driving research in key inter-disciplinary themes. Please see
> www.hw.ac.uk/researchleaders for further information and how to apply.
>
> Heriot-Watt University is a Scottish charity registered under charity number
> SC000278.

[Stian Soiland-Reyes]

Hi, I seem to have forgot about this thread..


I see that HCLS is using the suggested new properties in
http://www.w3.org/2001/sw/hcls/notes/hcls-dataset/

and realized that I better make sure PAV 2.3 gets out before HCLS
finishes by end of August!



I have prepared a beta release:

http://purl.org/pav/2.3/html

which should look very much like what I sent around in December, but
also with a new picture on top and some tweaks to the text.

The picture now includes a brief chain of versions, which should
ilustrate how to use the new properties.

If this is all good to go, then I can put it at http://purl.org/pav/
-- although there seem to be some googlecode update issues at the
moment:

https://code.google.com/p/support/issues/detail?id=33479&sort=-id&colspec=ID%20Type%20Status%20Priority%20Stars%20Owner%20Summary





I know we discussed that "equivalent" representation was not
necebsseraly the best term for your use cases as you have different
properties depending on abstraction level. However, when looking at
this with a fresh mind, I don't quite see the issue here - the set of
properties on a resource does not have to be equivalent just because
their content (e.g a CSV file) is equivalent. The content can also
differ in some respect, e.g perhaps there are no user comments
embedded in a snapshot version.

I think pav:hasVersion and pav:hasCurrentVersion makes most sense in
PAV when the object can be thought of as a kind of permalink, git tag
or snapshot of the "abstract" subject. If you just want to talk about
abstraction levels, perhaps prov:specializationOf or dct:hasVersion is
a better fit. I am not sure if I understand the HCLS Dataset approach
yet - as it seems to be in a bit of HTTP-Range-14 territority with a
resource being a dataset DESCRIPTION rather than a dataset - but in
what way would the content of the 'abstract dataset' not (at the time
of reading the RDF) be equivalent to the content of the current
version?


Any views on this approach.. and on what remains before we can release
this as the official new PAV?



However I see that HCLS have used a mixture of (your suggested)
pav:isVersionOf and dct:isVersionOf, which is a bit confusing.

http://www.w3.org/2001/sw/hcls/notes/hcls-dataset/
differs from
http://htmlpreview.github.io/?https://github.com/joejimbo/HCLSDatasetDescriptions/blob/master/Overview.html

where the second has used consistently dct:isVersionOf.


I would argue that:

a) If B is an official version from the abstract dataset A, then one
should have:

A pav:hasVersion B .

b) If C is a third-party derivation of B, but still a specialization
of the abstract dataset A, then one should rather have:
C prov:specializationOf A.
C pav:derivedFrom B.

The type of derivation depends on what the change is.. E.g. changing a
Turtle file to JSON-LD might just be a pav:importerFrom.


I feel the use of dct:isVersionOf instead here is munging together
provenance and hierarchy of a resource's official status.




There is a statement:


> A version level description MUST use the dct:isVersionOf property to relate to the summary level description. The versions of the summary level resource may then be inferred due to the declared inverse property pav:hasVersion.
>
> :chembl17
> dct:isVersionOf :chembl .


This is not true, dct:isVersionOf does not have any formal inverses.
pav:hasVersion is a subproperty of dct:hasVerison, but dct:hasVersion
is not formally an inverse of dct:isVersionOf (and the subproperty
would not anyway be inferred).

I would rather use.

:chembl
pav:hasVersion :chembl17


in this case.

:chembl17 prov:specializationOf :chembl

is inferred because pav:hasVerison is a subproperty of its inverse
prov:generalizationOf.




I wanted to check with you first before bunching into the mailing list
with these comments (I just signed up to join the HCLS group).

On 17 December 2013 14:52, Stian Soiland-Reyes