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

VladimirAlexiev commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

The plan is to move away from mdand 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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

We should have a discussion on this on how to proceed

Sveino / Inst4CIM-KG

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