Using package URLs to identify some SoftwarePackage

[aamedina]

Addresses #227

• rdfs:seeAlso.
• The d3f:definition is sourced from OCSF "package" object dictionary property "purl" via rdfs:isDefinedBy.

[netfl0]

should be subclass of d3f:URL

[aamedina]

Should we update the definition of d3f:URL then? This is what informed my modeling decision:

:URL a owl:Class ;
    rdfs:label "URL" ;
    skos:altLabel "Uniform Resource Locator" ;
    rdfs:subClassOf :Identifier,
        [ a owl:Restriction ;
            owl:onProperty :addresses ;
            owl:someValuesFrom :Resource ] ;
    rdfs:isDefinedBy <http://dbpedia.org/resource/Uniform_Resource_Locator> ;
    :definition "A Uniform Resource Locator (URL), commonly informally termed a web address (a term which is not defined identically) is a reference to a web resource that specifies its location on a computer network and a mechanism for retrieving it.A URL is a specific type of Uniform Resource Identifier (URI), although many people use the two terms interchangeably. A URL implies the means to access an indicated resource, which is not true of every URI. URLs occur most commonly to reference web pages (http), but are also used for file transfer (ftp), email (mailto), database access (JDBC), and many other applications." ;
    rdfs:seeAlso "https://schema.ocsf.io/objects/url" .

The definition (including the semantics) implies that the URL is meant to access the indicated resource, which isn't the case with purls. It is meant as the identity of some package.

[netfl0]

should be :addresses

(for consistency. we may improve this in future)

[aamedina]

I am not sure that a purl addresses a package.

x addresses y: Relates a pointer x to a digital artifact y located in the address space to which x points. The address space is part of some digital store, whether it be in memory, an image, or a persistent storage device.

It does identify a package. It may be associated with some artifact which is loaded into memory and would then become addressable (like the file:// pointing to a specific DLL in a binary analysis, which was compiled by the package identified by a PURL, and then now its code and data is loaded into memory and becomes an addressable resource, but that is a different artifact than the PURL that identifies its source).

[netfl0]

I was hinting we need to improve this :) This is how we use URL at the moment.

However, you are inspiring me to fix this now however.

https://d3fend.mitre.org/dao/artifact/d3f:URL/

There is a distinction between Locator and Identifier.

:locates
:references
:identifies

We need something to indicate the resolvability aspect.

[aamedina]

I admit I am kind of confused by the definition of PURL as a URL myself. I personally use it to identify a software package uniquely as a IRI, but the OCSF definition and the spec documented I linked do indicate that it can be used to "locate" the package as well as identify it. But semantically, PURLs can't control how package managers work, which would actually perform the resolution, I mean it would be nice if all package managers converged on a universal locator, but they are different concepts. It reminds me more of how a file hash is used to identify files. You can have many file hashes that identify the same file (md5 or sha256 etc, each one is different). A purl in my interpretation should unambiguously refer to some software package, but the actual identifier is just a string. You can have many PURLs refer to the same software package, with different qualifiers for example. Will continue to think about this.

[netfl0]

should be rdfs:seeAlso , not defined by. We must to keep it semantic.

[aamedina]

OK. My thinking was in this case I think the PURL spec truly is "defining" the concept. Will update.

[netfl0]

This definition needs to be abstracted. It should be concise. This would be defining a concept d3f:PURLPackageURL if that makes sense. This would be a very specific type of package url.

[aamedina]

I know what you mean, in that case I would prefer it be called d3f:PURL I think.

[aamedina]

I removed the :PURL class and instead reverted to a previous idea which was to use a inverse functional property to identify some software package by URL. Then we don't need a new class for the "Package URL".

Let me know your thoughts on this approach.

:purl a owl:InverseFunctionalProperty,
        owl:ObjectProperty ;
    rdfs:label "has package URL" ;
    skos:altLabel "purl" ;
    rdfs:subPropertyOf :identified-by ;
    rdfs:domain :SoftwarePackage ;
    rdfs:range :URL ;
    rdfs:comment "A purl is a URL string used to identify and locate a software package in a mostly universal and uniform way across programming languages, package managers, packaging conventions, tools, APIs and databases." ;
    rdfs:isDefinedBy <https://schema.ocsf.io/objects/package> ;
    :definition "x has package URL y: The subject software package x is identified by the package URL y." ;
    rdfs:seeAlso <https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rst> .