Proposed vocab metadata

[berezovskyi]

No description provided.

[ndjc]

This issue currently tries to describe the proposed set of metadata by referencing a delta between two versions of the Core vocab, or if you like, by reference to the entirety of the newer version. But even with the comments, that doesn't really tell me what each term is used for and why it is present - and it certainly wont tell future OSLC spec developers that.

What I think we should do here is write a resource shape for our vocabularies - that is, for our use of the class owl:Ontology. In this resource shape, we can use the description field to indicate our use of each property of the ontology, when it should be set, and what reviewers should verify.

This would also help me update ShapeChecker to look for the right properties on vocabularies.

I'm OK with volunteering to start doing that, but not this week - I could probably have a draft shape to review before next week's meeting.

[jamsden]

This is a lot of stuff to maintain manually. I foresee the potential for errors. Is all this needed? Can we minimize? I still thing dcterms:source with the URL to the actual repo release version is all that's needed. Following that link will provide all the rest of the information.

[jamsden]

Do we need to hold up release of Core PS01 or COS01 for that matter, for this feature? I hope not.

It feels like we might be over-engineering the process at the expense of getting the specs to OASIS Standard. All that good work goes to waste if we don't get the specs published.

Let's do the right thing of course, but understand the tradeoffs.

[berezovskyi]

No Jim, go ahead with your plan. Nick, I like your suggestions. Let’s work on that. Cheers, Andrew

…

________________________________ From: Jim Amsden <[email protected]> Sent: Thursday, June 4, 2020 10:47 PM To: oslc-op/oslc-specs Cc: Andrew Berezovskyi; Author Subject: Re: [oslc-op/oslc-specs] Proposed vocab metadata (#325) Do we need to hold up release of Core PS01 or COS01 for that matter, for this feature? I hope not. It feels like we might be over-engineering the process at the expense of getting the specs to OASIS Standard. All that good work goes to waste if we don't get the specs published. Let's do the right thing of course, but understand the tradeoffs. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#325 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAAPZXVGGHWALLNS6ARQD63RVAB4NANCNFSM4NSZKGSQ>.

[jamsden]

• dcterms:license http://www.apache.org/licenses/LICENSE-2.0 ; # isn't this redundant with the file copyright notice?
• dcterms:relation https://github.com/oslc-op/oslc-specs/blob/master/specs/core/vocab/core-vocab.ttl ; # seems redundant with dcterms:source, the fact that that source is part of something is in the repo
• dcterms:modified "2020-06-04"^^http://www.w3.org/2001/XMLSchema#date ; # OK
• dcterms:issued "2020-06-04"^^http://www.w3.org/2001/XMLSchema#date ; # redundant with dcterms:subject
• dcterms:hasVersion "WD" ; # redundant with dcterms:subject (i.e., functionally dependent)
• oslc_asset:tag rdf:nil ; # use dcterms:subject
• dcterms:isPartOf https://oslc-op.github.io/oslc-specs/specs/core/oslc-core.html ; # redundant or unnecessary
• dcterms:source https://github.com/oslc-op/oslc-specs/blob/master/specs/core/vocab/core-vocab.ttl # good, and should point to the actual version that was modified and tagged, not latest on HEAD, etc.

[berezovskyi]

Thanks for taking a look, Jim.

The license property is nice to have but not necessary. The advantage over the header is that it’s machine readable ofc.

The dcterms:source will point to the exact source location as we agreed.

The purpose of the dcterms:relation property is to exactly point to the HEAD version at all times. Theoretically, relation can be removed. I wanted to have it in case we point to the file in the oasis archive via the dc:source.

I will remove tag and version in favor of dc:subject.

I can remove the ‘issued’ property, though I don’t consider it to be redundant that much.

In general, I dislike how we label properties to be redundant. We need to remember that the whole purpose of reasoning is to produce redundant data (ie reasoners merely produce redundant inferences). Also, we make all of the properties in RDF readable for machines, not for humans. A machine cannot easily deduce that the vocab has Apache license or is part of the Core 3.0 PS spec. So, I think we shall apply this line of thinking to keep ‘license’ and ‘isPartOf’ properties intact.

[berezovskyi]

@jamsden @ndjc I want to add similar metadata to the shapes. I think it will be best to define a class like oslc:DomainSpecification so that we can say in the shapes file:

. a oslc:DomainSpecification ; all the necessary metadata

Other possible class names:

• Shapes
• ShapesSpecification

I have seen declarations like : dcterms:modified “2020-06-12”^^xsd:date but that will look a bit strange and will only be readable by dynamic means and will not allow a ShapeChecker shape to be defined.

Also, any properties you wish to add?

[ndjc]

dcterms:license is in fact a requirement for our internal IBM vocabularies, and I see no problem in requiring it for OSLC ones.
There does seem to be some overlap between dcterms:relation, dcterms:source, and dcterms:isPartOf; can we define some use cases that call out the need for these?

[berezovskyi]

We might want to define multiple sets of shapes per domain, a less prescriptive name may be better, e.g. ShapeCollection or Shapes.

[berezovskyi]

The vocab metadata was pushed in #329 and shape metadata was extracted into #354