namespace hijacking; CGMES-NC Header-AP-Voc-RDFS2020 wrong terms

[VladimirAlexiev]

These terms in CGMES-NC Header-AP-Voc-RDFS2020 are junk: not meaningful names, namespace hijacking (dcat, dcterms), start with uppercase. Must be fixed:

dcat:Resource7 a rdf:Property ;
dcat:Resource8 a rdf:Property ;
dcterms:Resource1 a rdf:Property ;
dcterms:Resource10 a rdf:Property ;
dcterms:Resource11 a rdf:Property ;
dcterms:Resource12 a rdf:Property ;
dcterms:Resource13 a rdf:Property ;
dcterms:Resource2 a rdf:Property ;
dcterms:Resource3 a rdf:Property ;
dcterms:Resource4 a rdf:Property ;
dcterms:Resource5 a rdf:Property ;
dcterms:Resource6 a rdf:Property ;

Here both the URL and type are wrong:

rdf:LangString a rdfs:Class ;

The correct is rdf:langString a rdfs:Datatype. Please fix the URL (you use as cims:dataType) and don't repeat a definition (it's a standard term).

The URL is wrong (uppercase), and the comment has a grammatical error:

prov:Entity a rdf:Property ;
  rdfs:comment "The entity that generated by this activity." ;

These external terms are defined anew. This is considered namespace hijacking and should be avoided.
Unless there's a good reason for it, eg you change the definition to something more appropriate to CGMES/NC, or fix the domain.

adms:versionNotes a rdf:Property ;
dcat:endDate a rdf:Property ;            
dcat:hasVersion a rdf:Property ;         
dcat:inSeries a rdf:Property ;           
dcat:isVersionOf a rdf:Property ;        
dcat:keyword a rdf:Property ;            
dcat:nextVersion a rdf:Property ;        
dcat:previousVersion a rdf:Property ;    
dcat:seriesMember a rdf:Property ;       
dcat:startDate a rdf:Property ;          
dcat:temporalResolution a rdf:Property ; 
dcat:version a rdf:Property ;            
dcterms:accessRights a rdf:Property ;
dcterms:accrualPeriodicity a rdf:Property ;
dcterms:conformsTo a rdf:Property ;
dcterms:creator a rdf:Property ;
dcterms:description a rdf:Property ;
dcterms:identifier a rdf:Property ;
dcterms:issued a rdf:Property ;
dcterms:license a rdf:Property ;
dcterms:publisher a rdf:Property ;
dcterms:references a rdf:Property ;
dcterms:replaces a rdf:Property ;
dcterms:rights a rdf:Property ;
dcterms:rightsHolder a rdf:Property ;
dcterms:source a rdf:Property ;
dcterms:spatial a rdf:Property ;
dcterms:title a rdf:Property ;
dcterms:type a rdf:Property ;
euvoc:status a rdf:Property ;
prov:atLocation a rdf:Property ;       
prov:generatedAtTime a rdf:Property ;  
prov:hadPrimarySource a rdf:Property ; 
prov:specializationOf a rdf:Property ; 
prov:wasAttributedTo a rdf:Property ;  
prov:wasGeneratedBy a rdf:Property ;   
prov:wasInfluencedBy a rdf:Property ;  
prov:wasRevisionOf a rdf:Property ;    

I doubt the value of redefining external terms.
Eg this one has 2 unmerged definitions.
And if it's deprecated, why even use it and redefine it?

dcat:hasVersion a rdf:Property ;
  rdfs:comment 
"""This resource has a more specific, versioned resource.
This property is intended for relating a non-versioned or abstract resource to several versioned resources, e.g. snapshots [PAV].
The notion of version used by this property is limited to versions resulting from revisions occurring to a resource as part of its life-cycle. Therefore, its semantics is more specific than its super-property dcterms:hasVersion, which makes use of a broader notion of version, including editions and adaptations.
This property is deprecated.""", 

"""This resource is a version of a non-versioned or abstract resource.
This property is intended for relating a versioned resource to a non-versioned or abstract resource.
The notion of version used by this property is limited to versions resulting from revisions occurring to a resource as part of its life-cycle. Therefore, its semantics is more specific than its super-property dcterms:isVersionOf, which makes use of a broader notion of version, including editions and adaptations.""" ;

[griddigit-ci]

In the last release we clean up the deprecated stuff.
On the part dcterms:Resource6 a rdf:Property this comes from the declaration of the inverse associations. in order to be able to export them we need for association end role name and in cases where dcat or cterms does not define we had to invent something.
We need to discuss how to solve this.

[VladimirAlexiev]

In ontologies, it is recommended to just use external terms (optionally using owl:imports), but not redefine them.

In the UML you cannot use an external term unless you also define it in the UML?

[VladimirAlexiev]

While analyzing datatype prop ranges, I found more cases of namespace hijacking.
@Sveino PowerSystemProjectGroup is brand new, right?
So @griddigit-ci please check whether "In the last release we clean up the deprecated stuff" is actually done.

dcat:Resource.hasVersion	xsd:anyURI
dcat:Resource.isVersionOf	xsd:anyURI
dcat:Resource.keyword	xsd:string
dcat:Resource.version	xsd:string
dcat:Resource.versionNotes	xsd:string
dcat:endDate	xsd:dateTimeStamp
dcat:keyword	xsd:string
dcat:startDate	xsd:dateTimeStamp
dcat:temporalResolution	xsd:duration
dcat:version	xsd:string
dct:PowerSystemProjectGroup.description	xsd:string
dct:PowerSystemProjectGroup.identifier	xsd:string
dct:PowerSystemProjectGroup.title	xsd:string
dct:Resource.accessRights	xsd:string
dct:Resource.conformsTo	xsd:string
dct:Resource.creator	xsd:string
dct:Resource.description	xsd:string
dct:Resource.identifier	xsd:string
dct:Resource.issued	xsd:dateTime
dct:Resource.license	xsd:string
dct:Resource.modified	xsd:date
dct:Resource.publisher	xsd:string
dct:Resource.rights	xsd:string
dct:Resource.rightsHolder	xsd:string
dct:Resource.title	xsd:string
dct:description	xsd:string
dct:identifier	xsd:string
dct:issued	xsd:dateTime
dct:rights	xsd:string
dct:rightsHolder	xsd:string
dct:title	xsd:string
rdf:Statement.object	xsd:string
rdf:Statement.predicate	xsd:string
rdf:Statement.subject	xsd:string

[VladimirAlexiev]

These two files have a variety of differences.
If you're on Windows, install TortoiseGit (an excellent integration of git into Explorer) and use this:

cd rdfs-improved
TortoiseGitMerge CGMES/ttl/61970-600-2_Header-AP-Voc-RDFS2019_v3-0-0.ttl CGMES-NC/ttl/Header-AP-Voc-RDFS2020.ttl

Please make the files identical. From spelling fixes (is the kept same vs is kept the same), the latter is the more recent version

Some of the differences are:

• CGMES-NC/ttl/Header-AP-Voc-RDFS2020 has more hijacked terms
• It defines a dataspace dcat-cim: in which it creates its own versions of dcat terms.
  This is a veiled form of namespace hijacking. Simply use DCAT terms, don't define your own versions.
• It relaxes some props to non-mandatory (cims:M:0..1)
• Fixes rdf:Statements to rdf:Statement(butrdf:Statement.predicate` is still a hijacking, and wrong prop name)
• Fixes md:Model.version from xsd:integer (IMHO wrong) to xsd:string)

[Sveino]

dcat-cim should only represent the CIM extension of DCAT. I have send an email addressing the detail.

Fixes md:Model.version from xsd:integer (IMHO wrong) to xsd:string)

I agree. This is not a problem when converting md:Model.version -> dcat:version but the revers would be difficult. I think we just then break the md:Model.version contraints.

[VladimirAlexiev]

dcat-cim: do you need another namespace for just a few terms? You got md.

Version as integer: then eg "002" would be returned as 2. And using multiple components may make sense, eg "2.5.3"

[Sveino]

The plan is to move away from md and dm. If you like the dcat-cim (needed for alternative dataset) we will try to get it into dcat standard.
I am OK that we might have issue to move from dcat:version to md:version.

[Sveino]

you ask:

PowerSystemProjectGroup is brand new, right?
Yes, but I think we need to change this model. However, both PowerSystemProjectGroup and PowerSystemProject should be in NC namespace.

[VladimirAlexiev]

• What props will you have in dcat-cim?
• As for proposing it for standardization: I'm at https://semantic.internationaldataspaces.org and right now there's a big discussion of DCAT profiles (DCAT-AP, GeoDCAT-AP, BregDCAT-AP, MobilityDCAT-AP, etc) and people are saying "that's too many!"
• Maybe coming from the electricity industry your additions will be accepted. But even if it doesn't get accepted for standardization, doesn't mean you cannot use these new props

[griddigit-ci]

We should have a discussion on this on how to proceed