See Principles and concepts#wiki-delegation

Combination of version and with_metadata views

Given that we now have the default being that entities are normally versioned by using named graphs I’m not sure that _view=version on its own is so useful. Should it imply with_metadata?

It might also be more uniform to call it with_version or with_versioninfo.

The registry API supports conneg for viewing all resources, providing a user interface for the HTML view and RDF data for at least Turtle and RDF/XML.

In some settings (including implementing a UI client side) it is convenient to be able to specify and override the returned format as part the URI pattern.

The POC supports this through the _format=ttl and _format=rdf arguments.

Proposed: make this an explicit part of the API specification.

Alternative syntaxes are possible including using a ".ttl" or ".rdf" suffix at the end of the URI, prior to the query string. Given the high use of query parameters in the API I find the notion of an explicit format parameter more appealing.

Am trying to figure out if I can upload multiple sets of entities (with associated register items) into an existing register ... potential time-saver :-)

It doesn't work.

Am I doing something wrong? Is the easiest way to work around this simply to script one request per entity? ... a little time consuming with hundreds (or more) of entities to register, but workable; it might also quickly create a big version graph for the register if I sequentially add a 100+ entities to a given register.

note: I don't want to do a "batch" update because I want explicit control over the register item properties (e.g. additional domain-specific properties) and I don't thing I can do this with the batch upload ... I think this is used for, say, uploading in one step an existing skos ConceptScheme and associated concepts as a register plus entities.

Here's what I did:

file: number-eleven-twelve-post.ttl

@Prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
@Prefix dct: http://purl.org/dc/terms/ .
@Prefix reg: http://purl.org/linked-data/registry# .
@Prefix skos: http://www.w3.org/2004/02/skos/core# .
@Prefix prov: http://www.w3.org/ns/prov# .

<>
a reg:RegisterItem ;
reg:definition
[ reg:entity http://ukgovld-registry.dnsalias.net/def/numbers/eleven
] ;
reg:itemClass skos:Concept ;
reg:notation "eleven" ;
reg:register http://ukgovld-registry.dnsalias.net/def/numbers ;
prov:wasAttributedTo http://jeremytandy.me.uk/self#id ;
reg:status reg:statusStable ;
.

http://ukgovld-registry.dnsalias.net/def/numbers/eleven
a skos:Concept ;
rdfs:label "eleven"@en ;
dct:description "Equivalent to the sum of six and five; one more than ten; 11."@en ;
.

<>
a reg:RegisterItem ;
reg:definition
[ reg:entity http://ukgovld-registry.dnsalias.net/def/numbers/twelve
] ;
reg:itemClass skos:Concept ;
reg:notation "twelve" ;
reg:register http://ukgovld-registry.dnsalias.net/def/numbers ;
prov:wasAttributedTo http://jeremytandy.me.uk/self#id ;
reg:status reg:statusStable ;
.

http://ukgovld-registry.dnsalias.net/def/numbers/twelve
a skos:Concept ;
rdfs:label "twelve"@en ;
dct:description "Equivalent to the product of three and four; two more than ten; 12."@en ;
.

Action:

curl -i -H "Accept:text/plain" -H "Content-Type:text/turtle" -X POST --data "@number-eleven-twelve-post.ttl" http://ukgovld-registry.dnsalias.net/def/numbers

Response:

HTTP/1.1 100 Continue

HTTP/1.1 400 Bad Request
Server: nginx/1.2.6
Date: Sun, 03 Mar 2013 15:37:02 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: keep-alive

Entity path doesn't match its notation

Revised status codes to include new “invalid” code from ISO 19135 and clarify impact of code groups on registry operation.
See Principles and concepts#wiki-lifecycle

Just a comment :-)

the JSON-LD created by the registry is poorly styled ...

The benefit of JSON-LD is the familiarity for web-developers who work with JSON all the time. However, the JSON-LD rendered by the registry is very fragmented; lots of small object-graphs enclosed in the obligatory { @graph } object.

Given the choice (!) it would be far more preferable to try to nest the object-graphs to create fewer, deeper graphs. [I can provide an example if needed]

I realise that the registry is likely to incorporate software libraries from elsewhere that drive this behaviour - but food for thought.

I wanted to test whether I could upload a new managed entity (/def/numbers/eight) plus provide some additional metadata to the register item ... e.g.

i) arbitrary (domain-specific) properties ... I chose prov:wasAttributedTo for this example (doesn't matter if my usage is wrong - it's the principle that counts!)
ii) set the register item status to "stable" immediately at the point of upload

This results in a HTTP 400 "Bad request" response; I wasn't expecting that!

Setting the status post-upload is easy (esp. given the additional bulk status change API) but it would be advantageous to enable additional register item metadata (such as will be needed for WMO) to be uploaded at time of registration.

file: number-eight-post.ttl

@Prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
@Prefix dct: http://purl.org/dc/terms/ .
@Prefix reg: http://purl.org/linked-data/registry# .
@Prefix skos: http://www.w3.org/2004/02/skos/core# .
@Prefix prov: http://www.w3.org/ns/prov# .
<>
a reg:RegisterItem ;
reg:definition
[ reg:entity
] ;
reg:itemClass skos:Concept ;
reg:register http://ukgovld-registry.dnsalias.net/def/numbers ;
prov:wasAttributedTo http://jeremytandy.me.uk/self#id ;
reg:status reg:statusStable ;
.

a skos:Concept ;
rdfs:label "eight"@en ;
dct:description "Equivalent to the product of two and four; one more than seven, or two less than ten; 8."@en ;
.
}

Action:

curl -i -H "Accept:text/plain" -H "Content-Type:text/turtle" -X POST --data "@number-eight-post.ttl" http://ukgovld-registry.dnsalias.net/def/numbers

Response:

HTTP/1.1 400 Bad Request
Server: nginx/1.2.6
Date: Sun, 03 Mar 2013 13:05:55 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: keep-alive

Entity relative path doesn't match its notation

Further thinking about these pesky reserved entries leads me to conclude that I don't want them to impact the normal function of the register. Thus when one GETs the register, the reserved entries should not be included. (if you want to find them, you can dig!)

Thus "reserved" entries need to have status "NotAccepted" (or sub-type thereof). Neither "Submitted" nor "Invalid" really fit the desired semantics.

Best fit would be the introduction of a new status that is disconnected from the status lifecycle; e.g. it stands alone.

For example, a "reserved" entry would be specified with status "reg:statusReserved". When that entry is allocated, the register-manager should ensure that status is set to "reg:statusSubmitted" to begin the lifecycle as normal. (don't know if we can default this behaviour somehow?)

"reg:statusReserved" might be defined as:

reg:statusReserved a skos:Concept, reg:Status;
    skos:prefLabel "reserved"@en;
    rdfs:comment "A reserved entry allocated for some as yet undetermined future use."@en;
    skos:inScheme reg:StatusScheme;
    skos:broader  reg:statusNotAccepted;
    .

Requestor IP address is not being logged correctly in the Registry level logs (is present in proxy logs). Despite use of x-forwarded-for.

[for discussion regarding additional tools required to support register management]

The summary point is that tools like a "back-link" service (to identify where else a term is referenced) or a "watch" service (to notify a user of a change to a given term/register) will be extremely useful when managing a registry.

Question (from Andrea Splendiani):
What do you do when you obsolete a term that is contained in more registries ?

The situation is this:
you have a register for runaways:R
And have a term:1
hence our URI is R/1.

Now, as far as we keep containment and definition tight together, if we obsolete a term, this means it's out of the registry.

Now:

you have a register for Runaways certified to be good when wet: RCW
You add your new term to RCW.
So we have RCW contains R/1

What happens if you obsolete R/1 ?
It's easily reflected in R
What about RCW ?

In our previous model this was and wasn't an issue, in that by definition register could "contain" only entities they defined, while other entities could be differently related.
E.g.: RCW was a collection, otherwise basically an "entity" subject to versioning, that would contain obsoleted terms (without logical problems) until amended.

It may be that after all you still have a difference between definition and containment emerging.

Response (from Jeremy Tandy):

Your question (summarised): "what happens to register RCW when term R/1 is obsoleted in register R"

If you look at the information model [ https://github.com/der/ukl-registry-poc/wiki/Principles-and-concepts#wiki-model ] you will see that "status" is a property of the register item, which provides the metadata about the relationship between a single entity and a single register.

So when the register manager decides that term R/1 is no longer appropriate in register R, she will update the status of term R/1 with respect to register R.

Thus the register item associated with term R/1 (let's call it R/_1 using our preferred notation) now has properties like:

<R/_1>
a reg:RegisterItem ;
reg:register ;
reg:definition [ reg:entity <R/1> ] ;
reg:status reg:statusRetired .

Notice that term <R/1> still exists ... it's just that in the context of register it is no longer valid; I've used "statusRetired" to indicate this.

This does not affect register ; the register item* will still show properties such as:

<RCW/_6>
a reg:RegisterItem ;
reg:register ;
reg:definition [ reg:entity <R/1> ] ;
reg:status reg:statusValid .

• note that the register item identifier need not match the identifier of the registered entity itself; here let's assume that term <R/1> is the sixth term registered within .

Updates to register require some additional processing.

One of the additional tools that we expect to layer on top of the register is a "back-link" service that would enable one to quickly find all the entities within the register that refer to a given resource. Thus a "back-link" query against term <R/1> would return the two register items <R/_1> and <RCW/_6> which can then easily be investigated to determine the register that they are associated with. Thus the register manager (if they have the necessary permissions) could update register as necessary.

Alternatively, we also want to introduce a "watch" tool that allows interested parties to request notification if a term (etc.) is updated. This could be used to notify the register manager of who could then take the appropriate action.

There is an explicitly defined status lifecyle, which the registry enforces. For example, once something has been deprecated (e.g. retired) then it can only be invalidated but not taken out of retirement.

At least during development this rigid lifecyle enforcement has proved problematic.

The POC implements a "force" override so that item?update&force&status=s will set the item status to s even if that transition would normally not be legal.

It seems like that this will be needed in normal administration to undo mistakes.

Proposed: to add force to the API specification, noting that a security regime may impose different restrictions on use of this API.

In the continued search to figure out how to deal with WMO's peculiar habit of "reserving" items in a register for later use, I thought I would try the following:

within the "numbers" register

1. upload a concept in the "fifteen" slot that says its "reserved" etc. ... this is genuinely what it says; a "reserved concept"!
2. [time passes, and "fifteen" is allocated] PUT a new definition for "fifteen" in place.

I chose to PUT because I wanted to get rid of a "skos:broader" property I originally included to indicate a relationship with a generic "Reserved" concept.

However, when I attempted the PUT, I accidentally used HTTP POST method instead. Yes, this should fail, but an HTTP 500 response is pretty unfriendly!

The badly formed second operation results in the following error:

HTTP/1.1 500 Internal Server Error 
[...]
com.epimorphics.registry.core.Description cannot be cast to com.epimorphics.registry.core.Register

These errors are likely to occur now and again; can we catch and throw a more friendly exception?

(PS. it works fine when I use PUT method as intended!)

1. upload a "reserved" concept in the "fifteen" slot ...

file: number-fifteen-reserved-post.ttl

@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dct:     <http://purl.org/dc/terms/> .
@prefix reg:     <http://purl.org/linked-data/registry#> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .
@prefix prov:    <http://www.w3.org/ns/prov#> . 

[]
      a       reg:RegisterItem ;
      reg:definition
              [ reg:entity <http://ukgovld-registry.dnsalias.net/def/numbers/fifteen>
              ] ;
      reg:itemClass skos:Concept ;
      reg:notation "fifteen" ;
      reg:register <http://ukgovld-registry.dnsalias.net/def/numbers> ;
      reg:status reg:statusStable ;
      prov:wasAttributedTo <http://jeremytandy.me.uk/self#id> ;
      .

<http://ukgovld-registry.dnsalias.net/def/numbers/fifteen>
      a       skos:Concept ;
      rdfs:label "Reserved"@en ;
      dct:description "Reserved for future use."@en ;
      skos:broader <http://ukgovld-registry.dnsalias.net/reserved> ;
      .

action:

curl -i -H "Content-type:text/turtle" -H "Accept:text/plain" -X POST --data "@number-fifteen-reserved-post.ttl" http://ukgovld-registry.dnsalias.net/def/numbers

response:

HTTP/1.1 201 Created
Server: nginx/1.2.6
Date: Thu, 21 Mar 2013 14:03:59 GMT
Content-Length: 0
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/def/numbers/_fifteen

2. PUT a new definition for "fifteen" in place

file: number-fifteen-put.ttl

@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dct:     <http://purl.org/dc/terms/> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .

<http://ukgovld-registry.dnsalias.net/def/numbers/fifteen>
      a       skos:Concept ;
      rdfs:label "Fifteen"@en ;
      dct:description "15 (fifteen) is the natural number following 14 and preceding 16. In English, it is the smallest natural number with seven letters in its spelled name."@en ;
      .

action:

curl -i -H "Content-type:text/turtle" -H "Accept:text/plain" -X POST --data "@number-fifteen-put.ttl" http://ukgovld-registry.dnsalias.net/def/numbers/fifteen

response:

HTTP/1.1 500 Internal Server Error
Server: nginx/1.2.6
Date: Thu, 21 Mar 2013 14:12:01 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: keep-alive

com.epimorphics.registry.core.Description cannot be cast to com.epimorphics.registry.core.Register

Having registered a set of terms for "Runway deposit" types (including 5 "reserved" terms; 10-14), when I try to view the register using the web-UI I get a Internal Server Error (uncaught exception):

HTTP Status 500 - Invocation of method 'connectedNodes' in class com.epimorphics.rdfutil.RDFNodeWrapper threw exception com.epimorphics.util.EpiException: Attempted to find things connected to a non (URI) resource at register-list.vm[line 74, column 29]

My suspicion is that this is to do with the reserved nodes :)

Note that a standard command-line get works OK:

curl -i -H "Accept:text/turtle" http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/_0-20-086

HTTP/1.1 200 OK [...]

and

curl -i -H "Accept:text/turtle" http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086

HTTP/1.1 200 OK [...]

For reference, I include the file I used in the registration process etc:

action:

curl -i -H "Accept:text/plain" -H "Content-type:text/turtle" -X POST --data "@0-20-086-seven2fifteen-post.ttl" http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086

response:

HTTP/1.1 100 Continue

HTTP/1.1 201 Created
Server: nginx/1.2.6
Date: Tue, 26 Mar 2013 17:24:32 GMT
Content-Length: 0
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086/_15 

file (0-20-086-seven2fifteen-post.ttl):

@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dct:     <http://purl.org/dc/terms/> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .
@prefix reg:     <http://purl.org/linked-data/registry#> .
@prefix ldp:     <http://www.w3.org/ns/ldp#> .
@prefix bufr4-core: <http://codes.wmo.int/bufr4/structure/core#> .

[]
    a reg:RegisterItem ;
    reg:definition
        [ reg:entity <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086/7> ] ;
    reg:itemClass <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
    reg:register <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086> ;
    reg:status reg:statusStable ;
    reg:notation "7" ;
    bufr4-core:No 3047 ;
    bufr4-core:FXY "020086" ;
    bufr4-core:Status bufr4-core:statusOperational ;
    .
<http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086/7>
    a <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
    rdfs:label "Ice"@en ;
    .
[]
    a reg:RegisterItem ;
    reg:definition
        [ reg:entity <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086/8> ] ;
    reg:itemClass <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
    reg:register <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086> ;
    reg:status reg:statusStable ;
    reg:notation "8" ;
    bufr4-core:No 3048 ;
    bufr4-core:FXY "020086" ;
    bufr4-core:Status bufr4-core:statusOperational ;
    .
<http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086/8>
    a <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
    rdfs:label "Compact or rolled snow"@en ;
    .
[]
    a reg:RegisterItem ;
    reg:definition
        [ reg:entity <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086/9> ] ;
    reg:itemClass <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
    reg:register <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086> ;
    reg:status reg:statusStable ;
    reg:notation "9" ;
    bufr4-core:No 3049 ;
    bufr4-core:FXY "020086" ;
    bufr4-core:Status bufr4-core:statusOperational ;
    .
<http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086/9>
    a <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
    rdfs:label "Frozen ruts or ridges"@en ;
    .
[]
    a reg:RegisterItem ;
    reg:definition [
        reg:entity [
            a <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
            rdfs:label "Reserved"@en ;
            dct:description "Reserved for future use."@en ;
        ] ;
    ] ;
    reg:itemClass <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
    reg:register <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086> ;
    reg:notation "10" ;
    bufr4-core:No 3050 ;
    bufr4-core:FXY "020086" ;
    bufr4-core:Status bufr4-core:statusOperational ;
    .
[]
    a reg:RegisterItem ;
    reg:definition [
        reg:entity [
            a <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
            rdfs:label "Reserved"@en ;
            dct:description "Reserved for future use."@en ;
        ] ;
    ] ;
    reg:itemClass <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
    reg:register <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086> ;
    reg:notation "11" ;
    bufr4-core:No 3050 ;
    bufr4-core:FXY "020086" ;
    bufr4-core:Status bufr4-core:statusOperational ;
    .
[]
    a reg:RegisterItem ;
    reg:definition [
        reg:entity [
            a <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
            rdfs:label "Reserved"@en ;
            dct:description "Reserved for future use."@en ;
        ] ;
    ] ;
    reg:itemClass <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
    reg:register <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086> ;
    reg:notation "12" ;
    bufr4-core:No 3050 ;
    bufr4-core:FXY "020086" ;
    bufr4-core:Status bufr4-core:statusOperational ;
    .
[]
    a reg:RegisterItem ;
    reg:definition [
        reg:entity [
            a <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
            rdfs:label "Reserved"@en ;
            dct:description "Reserved for future use."@en ;
        ] ;
    ] ;
    reg:itemClass <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
    reg:register <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086> ;
    reg:notation "13" ;
    bufr4-core:No 3050 ;
    bufr4-core:FXY "020086" ;
    bufr4-core:Status bufr4-core:statusOperational ;
    .
[]
    a reg:RegisterItem ;
    reg:definition [
        reg:entity [
            a <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
            rdfs:label "Reserved"@en ;
            dct:description "Reserved for future use."@en ;
        ] ;
    ] ;
    reg:itemClass <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
    reg:register <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086> ;
    reg:notation "14" ;
    bufr4-core:No 3050 ;
    bufr4-core:FXY "020086" ;
    bufr4-core:Status bufr4-core:statusOperational ;
    .
[]
    a reg:RegisterItem ;
    reg:definition
        [ reg:entity <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086/15> ] ;
    reg:itemClass skos:Concept ;
    reg:register <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086> ;
    reg:status reg:statusStable ;
    reg:notation "15" ;
    bufr4-core:No 3051 ;
    bufr4-core:FXY "020086" ;
    bufr4-core:Status bufr4-core:statusOperational ;
    .
<http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086/15>
    a <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
    rdfs:label "Missing or not reported (e.g. due to runway clearance in progress)"@en ;
    .

Syntax for _versionAt={datetime} has not yet been discussed

Allocation of item identifiers (reg:notation)

ISO 19135 requires sequence numbers. der proposes permitting implementations to use uuids or a hash to permit distributed operation.

PATCH operation with mis-matched payload and HTTP request target still updates the resource identified in payload.

Was expecting some sort of HTTP 400 response (bad request).

file:colours-patch.ttl

@Prefix dct: http://purl.org/dc/terms/ .

http://ukgovld-registry.dnsalias.net/def/colours
dct:description "Register to hold a code list of PRIMARY colours"@en .

Action:

curl -i -H "Content-Type:text/turtle" -H "Accept:text/plain" --data "@colours-patch.ttl" -X PATCH http://ukgovld-registry.dnsalias.net/def/codes?non-member-properties

(payload targets /def/colours whilst request targets /def/codes (which doesn't actually exist))

Response:

HTTP/1.1 204 No Content
Server: nginx/1.2.6
Date: Sat, 02 Mar 2013 15:18:54 GMT
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/def/_colours:10

The /def/colours resource is updated; accordingly the /def/_colours register item is also updated.

Using curl to request a delegated resource (proxy mode); e.g. Spittal bathing water ...

curl -i -H "Accept:text/turtle" http://ukgovld-registry.dnsalias.net/def/eabw/ukc2102-03600

works fine ... an example triple:

bw:ukc2102-03600 def-bw:waterQualityImpactedByHeavyRain "true"^^xsd:boolean .

However, if we use a browser* to access the same resource, the HTML rendering (in browser) includes embedded URIs such as:

http://ukgovld-registry.dnsalias.net/def/bathing-water/waterQualityImpactedByHeavyRain

This does not match the data and gets a HTTP 404 response.

Furthermore, the HTML source states (line 416):

This is the correct URI for the predicate!

Further inspection indicates that all URIs in the HTML source matching the pattern

^http://environment.data.gov.uk/def/bathing-water/*

... are rendered in browser as:

http://ukgovld-registry.dnsalias.net/def/bathing-water/*

Given that the HTML source is correct, this is not a server side error.

My guess is that the presence of the "Content-Location" HTTP response header is confusing the browser; e.g.

Content-Location:http://environment.data.gov.uk/doc/bathing-water/ukc2102-03600.html

A quick search on the web indicates that Content-Location behaviour is problematic & not consistently implemented irrespective of what RFC 2616 section 14.14 states.

Your thoughts?

Jeremy

• tried current versions of Chrome & Firefox on Win7 plus IE9

I would expect the web UI search to return (at least one) positive "hit" for the term "Spittal" ... this is part of the delegated register /def/bathingWaters [http://environment.data.gov.uk/doc/bathing-water/ukc2102-03600]

I get zero "hits".

I imagine that this is because the Search component is currently only accessing the (default graph in) the local triple store?

When do you anticipate "federated search" being available?

The WMO code-tables often 'reserve' entries for later use.

For example, see WMO BUFR code-table 0-20-086 'Runway deposits':

0 20 086
Runway deposits
Code figure Status
0 Clear and dry Operational
1 Damp Operational
2 Wet with water patches Operational
3 Rime and frost covered (depth normally less than 1 mm) Operational
4 Dry snow Operational
5 Wet snow Operational
6 Slush Operational
7 Ice Operational
8 Compacted or rolled snow Operational
9 Frozen ruts or ridges Operational
10-14 Reserved Operational
15 Missing or not reported (e.g. due to runway clearance in progress) Operational

Entries 10-14 are 'reserved'.

I would like to be able to update the registry via the API to reflect this state.

Assuming that the register was at http://data.wmo.int/def/bufr/codeflag/0-20-086 I would like to be a POST one or more 'reserved' register items to that register. For example:

POST http://data.wmo.int/def/bufr/codeflag/0-20-086
{
@Prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# .
@Prefix reg: http://purl.org/linked-data/registry# .
@Prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
<>
a reg:RegisterItem ;
rdfs:label "Reserved"@en ;
reg:notation "10" ;
reg:itemClass http://data.wmo.int/def/bufr/b/0-20-086 ;
reg:definition [ a reg:EntityReference ; reg:entity rdf:nil ] ;
reg:status reg:statusNotAccepted .
<>
a reg:RegisterItem ;
rdfs:label "Reserved"@en ;
reg:notation "11" ;
reg:itemClass http://data.wmo.int/def/bufr/b/0-20-086 ;
reg:definition [ a reg:EntityReference ; reg:entity rdf:nil ] ;
reg:status reg:statusNotAccepted .
<>
a reg:RegisterItem ;
rdfs:label "Reserved"@en ;
reg:notation "12" ;
reg:itemClass http://data.wmo.int/def/bufr/b/0-20-086 ;
reg:definition [ a reg:EntityReference ; reg:entity rdf:nil ] ;
reg:status reg:statusNotAccepted .
<>
a reg:RegisterItem ;
rdfs:label "Reserved"@en ;
reg:notation "13" ;
reg:itemClass http://data.wmo.int/def/bufr/b/0-20-086 ;
reg:definition [ a reg:EntityReference ; reg:entity rdf:nil ] ;
reg:status reg:statusNotAccepted .
<>
a reg:RegisterItem ;
rdfs:label "Reserved"@en ;
reg:notation "14" ;
reg:itemClass http://data.wmo.int/def/bufr/b/0-20-086 ;
reg:definition [ a reg:EntityReference ; reg:entity rdf:nil ] ;
reg:status reg:statusNotAccepted .
}

Am I right in assuming that the reg:register property is automatically specified?

Note that I have used rdf:nil to represent a null registered entity ... I'm not sure if this is strictly true because rdf:nil is an instance of rdfs:List. However, you get the idea that I want to declare the registered entity as NOT SPECIFIED (e.g. this is an empty register item). Can you suggest a more appropriate 'empty' entity?

Also note that the reg:itemClass has been specified (pointing to a fictional class definition that is a subclass of skos:Concept representing all the runway deposit types). Whilst the register item is empty, we know what type of thing it is intended to be reserved for.

Finally, given that this is 'reserved' I have selected the 'not accepted' status.

The API design calls for a 204 response in all cases where an action has been taken but there's no response to return.

This is wrong in the case of registration where a new item is created. In those cases the correct code is 201 (and the created resource should be in the Location header as already specified in the design).

The POC implements this modification.

Following on from issue #38, I am trying to add domain-specific metadata to an existing register item using PATCH.

I get an HTTP 204 response - but the additional property is missing when I look at the data - both from the API and using the SPARQL form (noting that I looked both at the VersionedThing and the current Version).

It is important to be able to add arbitrary properties to register items; e.g. domain-specific information about the use of the entity in their context.

Here's what I did ...

1. Add the concept

file: number-nine-post.ttl

@Prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
@Prefix dct: http://purl.org/dc/terms/ .
@Prefix skos: http://www.w3.org/2004/02/skos/core# .

Action:

curl -i -H "Accept:text/plain" -H "Content-Type:text/turtle" -X POST --data "@number-nine-post.ttl" http://ukgovld-registry.dnsalias.net/def/numbers

Response:

HTTP/1.1 201 Created
Server: nginx/1.2.6
Date: Sun, 03 Mar 2013 13:02:29 GMT
Content-Length: 0
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/def/numbers/_nine

2. Patch the register item to add the extra property

file: number-_nine_patch.ttl

@Prefix prov: http://www.w3.org/ns/prov# .

<_nine>
prov:wasAttributedTo http://jeremytandy.me.uk/self#id .

Action:

curl -i -H "Accept:text/plain" -H "Content-Type:text/turtle" -X PATCH --data "@number-_nine-patch.ttl" http://ukgovld-registry.dnsalias.net/def/numbers/_nine

Response:

HTTP/1.1 204 No Content
Server: nginx/1.2.6
Date: Sun, 03 Mar 2013 13:12:49 GMT
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/def/numbers/_nine:2

3. Query the data (SPARQL form)

SELECT ?p ?o
WHERE {
http://ukgovld-registry.dnsalias.net/def/numbers/_nine:2 prov:wasAttributedTo ?o .
}

returns zero results.

4. Query the data (API)

Action:

curl -i -H "Accept:text/turtle" http://ukgovld-registry.dnsalias.net/def/numbers/_nine:2

Response:

HTTP/1.1 200 OK
Server: nginx/1.2.6
Date: Sun, 03 Mar 2013 13:29:26 GMT
Content-Type: text/turtle
Transfer-Encoding: chunked
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/def/numbers/_nine

@Prefix ...

http://ukgovld-registry.dnsalias.net/def/numbers/nine
a skos:Concept ;
rdfs:label "nine"@en ;
dct:description "Equivalent to the product of three and three; one more than eight, or one less than ten; 9."@en .

http://ukgovld-registry.dnsalias.net/def/numbers/_nine
a reg:RegisterItem ;
rdfs:label "nine"@en ;
dct:dateSubmitted "2013-03-03T13:02:29.861Z"^^xsd:dateTime ;
dct:description "Equivalent to the product of three and three; one more than eight, or one less than ten; 9."@en ;
reg:definition
[ reg:entity http://ukgovld-registry.dnsalias.net/def/numbers/nine ;
reg:sourceGraph http://ukgovld-registry.dnsalias.net/def/numbers/_nine:1#graph
] ;
reg:itemClass skos:Concept ;
reg:notation "nine" ;
reg:register http://ukgovld-registry.dnsalias.net/def/numbers ;
reg:status reg:statusSubmitted ;
owl:versionInfo 2 .

Following on from issue #33 I was testing the addition of a "referenced entity" to behave as a reserved item.

Because this is a referenced entity and I wanted to control the local identifier that was assigned to it within the scope of the number register I uploaded a register item and a few statements about the /reserved entity (from the perspective of the /def/numbers register).

I specified the URI of the register item as relative to /def/numbers : <_seven> ... and (because I wanted to use a numeric value for the notation) included the following triple:

<_seven> reg:notation "7" .

I expected the register item to be created as /def/numbers/_seven ... instead it was created as /def/numbers/_7

The value from the notation overrode the value I set.

I think this is fine but I had thought that if the register item identifier was specified (even as a relative identifier) that this would be used. I guess the documentation should be clarified to this effect: reg:notation is ALWAYS used to set the register item identifier.

Adding the "reserved" concept /reserved:

file: reserved-post.ttl

@Prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
@Prefix dct: http://purl.org/dc/terms/ .
@Prefix skos: http://www.w3.org/2004/02/skos/core# .

Action:

curl -i -H "Accept:text/plain" -H "Content-Type:text/turtle" -X POST --data "@reserved-post.ttl" http://ukgovld-registry.dnsalias.net

Response:

HTTP/1.1 201 Created
Server: nginx/1.2.6
Date: Sun, 03 Mar 2013 11:23:32 GMT
Content-Length: 0
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/_reserved

Adding the "reserved entry" in /def/numbers

file: number-seven-reserved-post.ttl

@Prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
@Prefix dct: http://purl.org/dc/terms/ .
@Prefix reg: http://purl.org/linked-data/registry# .
@Prefix skos: http://www.w3.org/2004/02/skos/core# .

<_seven>
a reg:RegisterItem ;
reg:definition
[ reg:entity http://ukgovld-registry.dnsalias.net/reserved
] ;
reg:itemClass skos:Concept ;
reg:notation "7" ;
reg:register http://ukgovld-registry.dnsalias.net/def/numbers ;
.

http://ukgovld-registry.dnsalias.net/reserved
a skos:Concept ;
rdfs:label "Reserved"@en ;
dct:description "Reserved for future use."@en ;

Action:

curl -i -H "Accept:text/plain" -H "Content-Type:text/turtle" -X POST --data "@number-seven-reserved-post.ttl" http://ukgovld-registry.dnsalias.net/def/numbers

Response:

HTTP/1.1 201 Created
Server: nginx/1.2.6
Date: Sun, 03 Mar 2013 11:45:10 GMT
Content-Length: 0
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/def/numbers/_7

An entry containing 'en' and 'fr' rdfs:label and dct:description results in a HTTP 400 Bad Request. Having undertaken a line-by-line assessment of the payload with another payload that registered without incident, the only differences (other than the reg:notation etc.) are the inclusion of an additional rdfs:label in French and two dct:description properties (English and French).

I cannot see anything wrong with the payload.

Furthermore, the reported error is odd:

Payload failed to parse: java.nio.charset.MalformedInputException: Input length = 1

This seems to be a bug.

action:

curl -i -H "Accept:text/plain" -H "Content-type:text/turtle" -X POST --data "@0-20-086-six-post.ttl" http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086

response:

HTTP/1.1 100 Continue

HTTP/1.1 400 Bad Request
Server: nginx/1.2.6
Date: Tue, 26 Mar 2013 20:27:03 GMT
Content-Type: text/plain
Transfer-Encoding: chunked
Connection: keep-alive

Payload failed to parse: java.nio.charset.MalformedInputException: Input length = 1

file (0-20-086-six-post.ttl):

@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dct:     <http://purl.org/dc/terms/> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .
@prefix reg:     <http://purl.org/linked-data/registry#> .
@prefix ldp:     <http://www.w3.org/ns/ldp#> .
@prefix bufr4-core: <http://codes.wmo.int/bufr4/structure/core#> .

[]
    a reg:RegisterItem ;
    reg:definition
        [ reg:entity <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086/6> ] ;
    reg:itemClass <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
    reg:register <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086> ;
    reg:status reg:statusStable ;
    reg:notation "6" ;
    bufr4-core:No 3046 ;
    bufr4-core:FXY "020086" ;
    bufr4-core:Status bufr4-core:statusOperational ;
    .
<http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086/6>
    a <http://ukgovld-registry.dnsalias.net/codes/common/c-15/ae/runwayDeposits> ;
    rdfs:label "Slush"@en ;
    dct:description "Snow or ice on the ground that has been reduced to a soft watery mixture by rain, warm temperature, and/or chemical treatment."@en ;
    rdfs:label "Neige fondante"@fr ;
    dct:description "Neige ou de glace sur le sol qui a été réduite à un doux mélange aqueux par la pluie, la température chaude et / ou le traitement chimique."@fr ;
    .

By default only items of accepted statuses (sp?) are visible but the status=s modifier allows all items with a status of s (or a narrower term than s) to returned.

In practice we need a name for the implicit root status to make it possible to list all entries in a register whatever their status.

In the POC we use status=any for that.

Proposed to make that an official part of the API

During experimentation with PUT operation, I broke the internal workings ...

Given the size of the mess I have created, it seems like we need some mechanism to prevent "accidents" happening ... options:

(A) make sure that important properties required for the successful operation of the registry are persisted and/or protected from external change,
(B) don't allow the PUT operation.

Also, I am not sure if this sorry tale indicates some bugs to resolve.

Here's the history of events:

1. Initial creation of sub-register "codes"

file: codes-post.ttl

@Prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
@Prefix reg: http://purl.org/linked-data/registry# .
@Prefix ldp: http://www.w3.org/ns/ldp# .

Action:

curl -i -H "Content-Type:text/turtle" -H "Accept:text/plain" -X POST --data "@codes-post.ttl" http://ukgovld-registry.dnsalias.net/

I notice that I forgot to add the description ... so

2. Amend /codes sub-register with additional description ...

file: codes-patch.ttl

@Prefix dct: http://purl.org/dc/terms/ .

http://ukgovld-registry.dnsalias.net/codes
dct:description "Root (sub-)register for WMO code-tables"@en .

Action:

curl -i -H "Content-Type:text/turtle" -H "Accept:text/plain" -X PATCH --data "@codes-patch.ttl" http://ukgovld-registry.dnsalias.net/codes?non-member-properties

So far, everything is still fine :-) ...

/codes is as follows:

http://ukgovld-registry.dnsalias.net/codes
a reg:Register , ldp:Container ;
rdfs:label "codes"@en ;
dct:description "Root (sub-)register for WMO code-tables"@en ;
reg:containedItemClass
reg:Register ;
reg:owner http://example.com/department ;
owl:versionInfo 2 .

but then I experimented to see what would happen with a PUT where the payload was missing triples; I wanted to see if properties like owl:versionInfo, rdf:type and reg:containedItemClass were "persistent" properties that couldn't be changed.

3. Update /codes sub-register with partial payload ...

file: codes-put.ttl

@Prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
@Prefix dct: http://purl.org/dc/terms/ .

http://ukgovld-registry.dnsalias.net/codes
rdfs:label "CODES"@en ;
dct:description "Root (sub-)register for WMO code-tables"@en ;
.

Action:

curl -i -H "Content-Type:text/turtle" -H "Accept:text/plain" -X PUT --data "@codes-put.ttl" http://ukgovld-registry.dnsalias.net/codes?non-member-properties

Response:

HTTP/1.1 204 No Content
Server: nginx/1.2.6
Date: Sat, 02 Mar 2013 17:00:19 GMT
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/_codes:3

... which didn't throw me any surprises; I thought that things had worked. However the Action:

curl -i -H "Accept:text/turtle" http://ukgovld-registry.dnsalias.net/codes

... yielded the following triples:

http://ukgovld-registry.dnsalias.net/codes
a reg:Register , ldp:Container ;
rdfs:label "codes"@en ;
dct:description "Root (sub-)register for WMO code-tables"@en ;
reg:containedItemClass
reg:Register ;
reg:owner http://example.com/department ;
owl:versionInfo 2 .

As you can see, the label has not been updated to "CODES" so I wondered if PATCH was working, so I tried to apply the change to the label property again ...

4. Amend /codes with new label (PATCH)

file: codes-patch2.ttl

@Prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .

http://ukgovld-registry.dnsalias.net/codes
rdfs:label "CODES"@en .

Action:

curl -i -H "Content-Type:text/turtle" -H "Accept:text/plain" -X PATCH --data "@codes-patch2.ttl" http://ukgovld-registry.dnsalias.net/codes?non-member-properties

Response:

HTTP/1.1 204 No Content
Server: nginx/1.2.6
Date: Sat, 02 Mar 2013 17:04:19 GMT
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/_codes:4

Again, we see the version number of the register item increment ... this time I checked the result in the browser; not looking good ...

Oops: Internal error (500)
Sorry but an internal error has occurred.

$response.entity

So I tried to fix the problem by updating /codes once more with all the properties that were included in version 2 ... with the exception of owl:versionInfo because I was not sure what this should be set at ...

5. Update /codes with complete payload - except owl:versionInfo (PUT) ... note that I appended a "+" character to the label and description to help spot any changes ...

file: codes-put2.ttl

@Prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
@Prefix dct: http://purl.org/dc/terms/ .
@Prefix reg: http://purl.org/linked-data/registry# .
@Prefix ldp: http://www.w3.org/ns/ldp# .

http://ukgovld-registry.dnsalias.net/codes
a reg:Register , ldp:Container ;
rdfs:label "CODES+"@en ;
dct:description "Root (sub-)register for WMO code-tables+"@en ;
reg:containedItemClass
reg:Register ;
reg:owner http://example.com/department ;
.

Action:

curl -i -H "Content-Type:text/turtle" -H "Accept:text/plain" -X PUT --data "@codes-put2.ttl" http://ukgovld-registry.dnsalias.net/codes?non-member-properties

Response:

HTTP/1.1 204 No Content
Server: nginx/1.2.6
Date: Sat, 02 Mar 2013 17:13:59 GMT
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/_codes:5

The browser still shows an internal server error (500) as before.

.../_codes?_view=version_list shows 5 register item versions as expected. However, the /codes register is described only with the following triples:

http://ukgovld-registry.dnsalias.net/codes
rdfs:label "CODES"@en ;
dct:description "Root (sub-)register for WMO code-tables"@en .

... this is the set I provided in step 3 (above).

Checking explicit versions of /codes ...

Action:

curl -i -H "Accept:text/turtle" http://ukgovld-registry.dnsalias.net/codes:1

Response (selected triples):

HTTP/1.1 200 OK
Server: nginx/1.2.6
Date: Sat, 02 Mar 2013 18:00:11 GMT
Content-Type: text/turtle
Transfer-Encoding: chunked
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/codes

@Prefix ...

http://ukgovld-registry.dnsalias.net/codes
a reg:Register , ldp:Container ;
rdfs:label "codes"@en , "CODES+"@en , "CODES"@en ;
dct:description "Root (sub-)register for WMO code-tables+"@en , "Root (sub-)register for WMO code-tables"@en ;
reg:containedItemClass
reg:Register ;
reg:owner http://example.com/department ;
owl:versionInfo 1 .

... and ...

Action:

curl -i -H "Accept:text/turtle" http://ukgovld-registry.dnsalias.net/codes:2

Response:

HTTP/1.1 200 OK
Server: nginx/1.2.6
Date: Sat, 02 Mar 2013 18:01:50 GMT
Content-Type: text/turtle
Transfer-Encoding: chunked
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/codes

@Prefix ...

http://ukgovld-registry.dnsalias.net/codes
a reg:Register , ldp:Container ;
rdfs:label "codes"@en , "CODES"@en ;
dct:description "Root (sub-)register for WMO code-tables"@en ;
reg:containedItemClass
reg:Register ;
reg:owner http://example.com/department ;
owl:versionInfo 2 .

... and (to make sure there are no more versions!) ...

Action:

curl -i -H "Accept:text/turtle" http://ukgovld-registry.dnsalias.net/codes:3

Response:

HTTP/1.1 500 Internal Server Error
Server: nginx/1.2.6
Date: Sat, 02 Mar 2013 18:02:48 GMT
Content-Type: text/turtle
Transfer-Encoding: chunked
Connection: keep-alive

Version requested on resource with no isVersionOf root

So by this stage, I can see that something quite odd has happened; all my extra properties have ended up in /codes:1 !!!

For info, the results of some SPARQL queries are:

SELECT ?g ?s ?p ?o
FROM NAMED http://ukgovld-registry.dnsalias.net/_codes:4#graph
WHERE {
GRAPH ?g { ?s ?p ?o . }
}

| g | s | p | o |
| http://ukgovld-registry.dnsalias.net/_codes:4#graph | ukreg:codes | dct:description | "Root (sub-)register for WMO code-tables"@en |
| http://ukgovld-registry.dnsalias.net/_codes:4#graph | ukreg:codes | rdfs:label | "CODES"@en |

/_codes:4#graph is cited in the response to /_codes?_view=version_list.

A query on /_codes:3#graph gives the same result whilst /_codes:1#graph and /_codes:2#graph return zero results.

Need a robots.txt configuration. Currently being hit by googlebot. Plus need to block baidu and setting nginx throttling

reg:submitter is cited as an automatic property.

obviously without authentication, we don't know who's doing what.

can we make sure that the automatic generation of reg:submitter is added once the Authentication and Access Control component is implemented?

Thanks.

Using the web UI to search for "reddish" returns, at the time of writing this issue, 4 positive hits.

Each of these hits is related to the /def/codes/red entity.

I suspect that these multiple positive hits are from finding the string "reddish" in the Versions of the register item (e.g. _red:2, _red:3, _red:4 and _red:5).

Given that all of these "hits" are referencing one unique entity, the search results need to be consolidated to provide a just one "hit" in this case.

Also, it would appear that the Search component is not checking the NAMED GRAPHS used for holding the information about entities (if this was the case, I assume that I would have seen 5 positive hits!).

It would seem prudent to check the NAMED GRAPHS in addition to the DEFAULT GRAPH; consolidation of hits based on the entity or register is still required.

Resolving the URI http://ukgovld-registry.dnsalias.net/def/eabw/ukc2102-03600 using a browser yields the response "HTTP referrer not valid". The OS-OpenSpace map widget does not render.

I suspect that this is because http://ukgovld-registry.dnsalias.net/ is not registered as related to the API key being used (which is intended for http://environment.data.gov.uk/).

This is not an issue with the Registry - just to note some unexpected behaviour that can be discounted.

Jeremy

The source for the Registry vocabulary appears to have a mistake (see lines 150-162; below):

reg:notation    a owl:DatatypeProperty;
    rdfs:label "notation"@en;
    rdfs:comment "A short text string which can be used to denote the register item. Must be unique within the register. If available it should be used as the path segment, relative to the parent register, for the RegisterItem (and for the item itself, if managed). Restricted to be a syntactically legal URI segment (i.e. *pchar)."@en;
    rdfs:domain reg:ItemRecord;
    rdfs:range  xsd:string;
    .

reg:itemClass    a owl:ObjectProperty;
    rdfs:label "item class"@en;
    rdfs:comment "The type of the entity that this record is about. Note that it may be possible to register a non-RDF resource in which case this property provides a way to state the intended class of the entity even though no direct RDF assertion of type is available."@en;
    rdfs:domain reg:ItemRecord;
    rdfs:range  rdfs:Class;
    .

In each case, the @RDFS:domain@ property is defined as @reg:ItemRecord@. This Class is not defined within the vocabulary - suggesting it is a legacy entry. I believe that these properties should be defined as @reg:RegisterItem@.

The current API design allows you to retrieve version information on a register item and from there walk back to previous versions. This means that getting a historical view of an item requires an unbounded series of search calls. For at least the UI, and thus probably for other tools, it would be more useful to be able to list all the known versions and be able to retrieve whatever subset of versions needed.

Suggestion, implemented in the POC, is to use {item}?_list=version_list for this. This call returns the normal item description (i.e. the current RegisterItem and current entity) plus minimal metadata on all known versions of that item. The metadata just gives the URI (from which the state of the item and entity at that version can be retrieved) and the interval during which the version was current.

For example:

curl -i -H "Accept:text/turtle" http://ukgovld-registry.dnsalias.net/def/colours/_red?_view=version_list

Returns:

<http://ukgovld-registry.dnsalias.net/def/colours/_red:1>
      a       <http://purl.org/linked-data/version#Version> , <http://purl.org/linked-data/registry#RegisterItem> ;
      <http://purl.org/dc/terms/isVersionOf>
              <http://ukgovld-registry.dnsalias.net/def/colours/_red> ;
      <http://purl.org/linked-data/version#interval> ... .

<http://ukgovld-registry.dnsalias.net/def/colours/_red:2>
      a       <http://purl.org/linked-data/version#Version> , <http://purl.org/linked-data/registry#RegisterItem> ;
      <http://purl.org/dc/terms/isVersionOf>
              <http://ukgovld-registry.dnsalias.net/def/colours/_red> ;
      <http://purl.org/linked-data/version#interval> ... .

<http://ukgovld-registry.dnsalias.net/def/colours/_red>
      a       <http://purl.org/linked-data/registry#RegisterItem> ;
      <http://www.w3.org/2000/01/rdf-schema#label>
              "reddish" ;
      <http://purl.org/dc/terms/dateSubmitted>
          "2013-02-1T23:17:09.223Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
      <http://purl.org/dc/terms/description>
              "A modified concept for the colour red" ;
      <http://purl.org/dc/terms/modified>
          "2013-02-1T23:17:10.715Z"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
      <http://purl.org/linked-data/registry#definition>
              [ <http://purl.org/linked-data/registry#entity>
                        <http://ukgovld-registry.dnsalias.net/def/colours/red> ;
                <http://purl.org/linked-data/registry#sourceGraph>
                        <http://ukgovld-registry.dnsalias.net/def/colours/_red:2#graph>
              ] ;
      <http://purl.org/linked-data/registry#itemClass>
              <http://www.w3.org/2004/02/skos/core#Concept> ;
      <http://purl.org/linked-data/registry#notation>
              "red" ;
      <http://purl.org/linked-data/registry#register>
          <http://ukgovld-registry.dnsalias.net/def/colours> ;
      <http://purl.org/linked-data/registry#status>
          <http://purl.org/linked-data/registry#statusSubmitted> ;
      <http://www.w3.org/2002/07/owl#versionInfo>
              2 .

<http://ukgovld-registry.dnsalias.net/def/colours/red>
      a       <http://www.w3.org/2004/02/skos/core#Concept> ;
      <http://www.w3.org/2000/01/rdf-schema#label>
              "reddish" ;
      <http://purl.org/dc/terms/description>
              "A modified concept for the colour red" .

Previously we agreed that the 'dateAmeneded' property (from ISO 19135:2005) was superfluous to our data model as it functionally covered by the version:interval property in the Version snapshot.

However, given that we often do not show the version information, it would be confusing to a user to be given a property talking about version intervals.

Proposal (A):

• the registry vocabulary includes the property reg:dateAmended (type xsd:dateTime).
• this property should be declared as cardinality [0..1] on reg:RegisterItem.
• this property would be inferred at query-time from the version information.

Note that the same argument applies to 'dateOfLastChange' (from ISO 19135:2005) ...

Proposal (B):

• the registry vocabulary includes the property reg:dateOfLastChange (type xsd:dateTime).
• this property should be declared as cardinality [0..1] on reg:Register.
• this property would be inferred at query-time from the version information.

Operation to amend a Register (PATCH) using json-ld payload is not supported.

Server response: "The server refused this request because the request entity is in a format not supported by the requested resource for the requested method."

file: colours-patch.jsonld

{
"@context" : { "dct" : "http://purl.org/dc/terms/" },
"@id" : "http://ukgovld-registry.dnsalias.net/def/colours",
"dct:description" : {
"@value" : "Register to hold a code list of PRIMARY-ish colours",
"@language" : "en"
}
}

Action:

curl -i -H "Content-Type:application/ld+json" -H "Accept:text/plain" --data "@colours-patch.jsonld" -X PATCH http://ukgovld-registry.dnsalias.net/def/colours?non-member-properties

The PATCH operation works fine for Content-Type:text/turtle.

(also note that the server ignores the "Accept:text/plain" header and provides HTML)

Having loaded domain-specific metadata into a register-item I expected to see this in the web UI.

Example:

resource: http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086

metadata request:

http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086?_format=ttl&_view=with_metadata

response (selected triples only):

[...]
<http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/_0-20-086>
    a       reg:RegisterItem ;
    rdfs:label "Runway deposits"@en ;
    bufr4-core:FXY "020086" ;
    bufr4-core:Status bufr4-core:statusOperational ;
    dct:dateSubmitted "2013-03-26T14:56:38.647Z"^^xsd:dateTime ;
    dct:description "WMO No. 306 Vol I.2 FM 94 BUFR (edition 4) Code-table 0 20 086 'Runway deposits'."@en ;
    reg:definition
            [ reg:entity <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086> ;
              reg:entityVersion <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag/0-20-086:1>
            ] ;
    reg:itemClass reg:Register ;
    reg:notation "0-20-086" ;
    reg:register <http://ukgovld-registry.dnsalias.net/codes/bufr4/codeflag> ;
    reg:status reg:statusStable ;
    owl:versionInfo 1 
    .
[...]

Yet the web-UI "metadata" tab only displays the following properties:

• description
• label
• type
• versionInfo

Is this problem because the web-UI does not know about the bufr4-core ontology?

Review the search API

I wanted to add another "reserved" item into the /def/numbers register. This works fine ... but when listing the /def/numbers members (http://ukgovld-registry.dnsalias.net/def/numbers) the "reserved" entity only appears once - not twice as expected. This doesn't show me the full list of register items ... only the entities! And the double reference to /reserved concept is consolidated.

By contrast, the view with_metadata explicitly shows both of the register items; /def/numbers/_7 and /def/numbers/_thirteen ... which is good.

However, in the web UI (register list; /def/numbers) both register items are displayed with the details from register item /def/numbers/_7 ... which is an error.

This is an edge case where the same concept is registered more than once within a register ... but could be important depending on how we resolve the requirement for dealing with "reserved" entries.

Here's what I did ...

/def/numbers/_7 already existed

file:

@Prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
@Prefix dct: http://purl.org/dc/terms/ .
@Prefix reg: http://purl.org/linked-data/registry# .
@Prefix skos: http://www.w3.org/2004/02/skos/core# .
@Prefix prov: http://www.w3.org/ns/prov# .

<>
a reg:RegisterItem ;
reg:definition
[ reg:entity http://ukgovld-registry.dnsalias.net/reserved
] ;
reg:itemClass skos:Concept ;
reg:notation "thirteen" ;
reg:register http://ukgovld-registry.dnsalias.net/def/numbers ;
reg:status reg:statusStable ;
prov:wasAttributedTo http://jeremytandy.me.uk/self#id ;
.

http://ukgovld-registry.dnsalias.net/reserved
a skos:Concept ;
rdfs:label "Reserved"@en ;
dct:description "Reserved for future use."@en ;
.

Action:

curl -i -H "Accept:text/plain" -H "Content-Type:text/turtle" -X POST --data "@number-thirteen-reserved-post.ttl" http://ukgovld-registry.dnsalias.net/def/numbers

Response:

HTTP/1.1 201 Created
Server: nginx/1.2.6
Date: Sun, 03 Mar 2013 15:55:14 GMT
Content-Length: 0
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/def/numbers/_thirteen

The notion of batch registration of ontologies and concept schemes was discussed but not in detail.

The current section on this as the end of registration

This probably needs clarifying and may need changing.

Earlier I commented that in WMO, it is common to "reserve" batches of numbers in a code-table for later allocation.

I tried to do this in the registry ...

Following guidance, I specified the entity within the reserved register item as a blank node, e.g.:

<> a reg:RegisterItem ;
reg:definition [ reg:entity [] ] ;
...
.

Using the SPARQL query I can see that I have created the register item and amended its status to experimental, but this reserved register item is not included in information that is provided via the API ... it's there but hidden.

Perhaps it would be more pertinent to reference a "reserved" concept that can be used as the place holder until the number is allocated?

Perhaps the registry could supply this "reserved" concept in the system register? e.g.

http://{registry}/system/reserved

Additionally, we have previously agreed that one cannot update the target entity for a register item once it has been accepted. To mitigate this perhaps we also need a special "reserved" status - sub-type of "valid" so that it appears in the lists!)

Alternatively, is it possible to include register items with empty "entities" in results?

Other ideas accepted!

For info, here's what I did to create the register item and update its status ...

file: number-six-reserved-post.ttl

@Prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
@Prefix dct: http://purl.org/dc/terms/ .
@Prefix reg: http://purl.org/linked-data/registry# .
@Prefix skos: http://www.w3.org/2004/02/skos/core# .

<>
a reg:RegisterItem ;
rdfs:label "Reserved"@en ;
dct:description "Reserved for future use"@en ;
reg:definition
[ reg:entity []
] ;
reg:itemClass skos:Concept ;
reg:notation "six" ;
reg:register http://ukgovld-registry.dnsalias.net/def/numbers ;
.

Action:

curl -i -H "Content-Type:text/turtle" -H "Accept:text/plain" -X POST --data "@number-six-reserved-post.ttl" http://ukgovld-registry.dnsalias.net/def/numbers

Response:

HTTP/1.1 201 Created
Server: nginx/1.2.6
Date: Sun, 03 Mar 2013 00:14:53 GMT
Content-Length: 0
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/def/numbers/_six

Action:

curl -i -H "Accept:text/plain" -X POST http://ukgovld-registry.dnsalias.net/def/numbers/_six?update\&status=experimental

Response:

HTTP/1.1 204 No Content
Server: nginx/1.2.6
Date: Sun, 03 Mar 2013 00:28:03 GMT
Connection: keep-alive

The form, whilst very useful, lacks support for the following output formats:

NTRIPLES
Turtle

Also, the JSON output is not JSON-LD.

Minor issue as this is a simple utility; I expect you are re-using existing components.

The registry supports batch validation (testing that all of a set of URIs are registered and in an accepted state). This is done through POSTing a list of URIs to a register.

For validating one off, or small numbers, of URIs it is a little more convenient to also be able to pass the URIs to check using query parameters.

This is implemented in the POC by allowing:

POST register?validate={uri1}&validate={uri2} ...

with an empty POST body.

Proposed: accept small addition to the spec

I tested to see what would happen if I patched an entity to add an additional french translation of the description property.

1. The patch worked fine.
2. The associated register item was also updated with the two descriptions - OK.
3. ISSUE: the web UI for "list" mode in the enclosing register only displays one of these descriptions ... and, by chance, it is not the one that matches my locale!
4. ISSUE: the description includes a unicode character from outside the "basic latin" range used for standard ASCII [0000–007F] - it's e-acute "é" unicode 00E9 ... this displays fine in the web UI (both for register list and entity itself) but looking at the data directly it is correct for the entity view http://ukgovld-registry.dnsalias.net/def/numbers/one?_format=ttl ("[...] la moitié des deux [...]") but is not correct for the register-item view http://ukgovld-registry.dnsalias.net/def/numbers/_one?_format=ttl ("[...] la moitié des deux [...]").

It seems unreasonable to expect the register list view to display more than one description ... but it would be good to (arbitrarily) select one that matches my locale!

(I guess that there are some hidden issues about finding strings for given locales ... { "one" } is not the same as { "one"@en } etc. ... should the register item include a description that is not coupled with a specific locale; perhaps chosen based on the locale of the registry if there is a choice of term?)

Also, the display of e-acute needs resolving.

Here's what I did ...

file: one-patch.ttl

@Prefix dct: http://purl.org/dc/terms/ .

http://ukgovld-registry.dnsalias.net/def/numbers/one
dct:description
"The smallest cardinal number, half of the two: 1."@en ,
"Le plus petit nombre cardinal, la moitié des deux; 1."@fr .

Action:

curl -i -H "Accept:text/plain" -H "Content-Type:text/turtle" -X PATCH --data "@one-patch.ttl" http://ukgovld-registry.dnsalias.net/def/numbers/one

Response:

HTTP/1.1 204 No Content
Server: nginx/1.2.6
Date: Sun, 03 Mar 2013 10:39:57 GMT
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/def/numbers/_one:3

A request for a specific version of register item returns:

1. the register item as it was for that version ... this is easy to see from the owl:versionInfo and the dct:description in the example cited below

2. the associate entity as the CURRENT version

This is counterintuitive; I would expect to be given the version of the associated entity that is contemporaneous with the requested version of the register item.

Action:

curl -i -H "Accept:text/turtle" http://ukgovld-registry.dnsalias.net/def/_colours:1

Response (selected triples):

http://ukgovld-registry.dnsalias.net/def/_colours
dct:description "Register to hold a code list of colours"@en ;
owl:versionInfo 1 ;
.

http://ukgovld-registry.dnsalias.net/def/colours
dct:description "Register to hold a code list of PRIMARY colours"@en ;
owl:versionInfo 12 ;
.

For reference, /def/colours:1 states ...

Action:

curl -i -H "Accept:text/turtle" http://ukgovld-registry.dnsalias.net/def/colours:1

Response (selected triples):

http://ukgovld-registry.dnsalias.net/def/colours
dct:description "Register to hold a code list of colours"@en ;
owl:versionInfo 1 ;
.

The general lifecycle of items is that when registered they are in state submitted and need to be approved to reach on of the accepted status levels at which they become visible in the register. The API already makes it easy to just change a status level for an item. Yet with the bulk registration facility it will be common to have an entire register full of items whose state is to be changed.

Proposed: add a batch status API. POST {register}?update&status=foo would update the status of all items currently in the target register to state foo.

I want to be able to batch-upload a collection (e.g. SKOS Collection) but also include explicit metadata for each member at the time of initial upload.

Having tried this (via the web-UI "batch" upload), it seems that the register item metadata is ignored. Note lack of @prov:wasAttributedTo@ property and @reg:status@ is stored as "submitted" rather than "stable".

A work around (that I will test next) is to create the register first then upload the entities with their explicit metadata.

file: letters2-a-b-c-webUI.ttl

@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dct:     <http://purl.org/dc/terms/> .
@prefix skos:    <http://www.w3.org/2004/02/skos/core#> .
@prefix reg:     <http://purl.org/linked-data/registry#> .
@prefix prov:    <http://www.w3.org/ns/prov#> .

<http://ukgovld-registry.dnsalias.net/def/letters2>
      a       skos:Collection ;
      rdfs:label "Letters (ISO basic Latin alphabet) [#2]"@en ;
      dct:description "The set of alphabetic characters (well - a few anyway)."@en ;
      reg:owner <http://jeremytandy.me.uk/self#id> ;
      skos:member <http://ukgovld-registry.dnsalias.net/def/letters2/a>, <http://ukgovld-registry.dnsalias.net/def/letters2/b>, <http://ukgovld-registry.dnsalias.net/def/letters2/c> ;
      .
<http://ukgovld-registry.dnsalias.net/def/letters2/a>
      a       skos:Concept ;
      rdfs:label "A"@en ;
      dct:description "A (named a /ˈeɪ/, plural aes) is the first letter and vowel in the ISO basic Latin alphabet. It is similar to the Ancient Greek letter alpha, from which it derives."@en ;
      .
[]
      a       reg:RegisterItem ;
      reg:definition
              [ reg:entity <http://ukgovld-registry.dnsalias.net/def/letters2/a>
              ] ;
      reg:itemClass skos:Concept ;
      reg:register <http://ukgovld-registry.dnsalias.net/def/letters2> ;
      prov:wasAttributedTo <http://jeremytandy.me.uk/self#id> ;
      reg:status reg:statusStable ;
      reg:notation "a" ;
      .
<http://ukgovld-registry.dnsalias.net/def/letters2/b>
      a       skos:Concept ;
      rdfs:label "B"@en ;
      dct:description "B (named bee /ˈbiː/) is the second letter in the ISO basic Latin alphabet. It is used to represent a variety of bilabial sounds (depending on language), but most commonly a voiced bilabial stop."@en ;
      .
[]
      a       reg:RegisterItem ;
      reg:definition
              [ reg:entity <http://ukgovld-registry.dnsalias.net/def/letters2/b>
              ] ;
      reg:itemClass skos:Concept ;
      reg:register <http://ukgovld-registry.dnsalias.net/def/letters2> ;
      prov:wasAttributedTo <http://jeremytandy.me.uk/self#id> ;
      reg:status reg:statusStable ;
      reg:notation "b" ;
      .
<http://ukgovld-registry.dnsalias.net/def/letters2/c>
      a       skos:Concept ;
      rdfs:label "C"@en ;
      dct:description "C (named cee /ˈsiː/) is the third letter in the ISO basic Latin alphabet. It is used to represent one hundred in Roman numerals."@en ;
      .
[]
      a       reg:RegisterItem ;
      reg:definition
              [ reg:entity <http://ukgovld-registry.dnsalias.net/def/letters2/c>
              ] ;
      reg:itemClass skos:Concept ;
      reg:register <http://ukgovld-registry.dnsalias.net/def/letters2> ;
      prov:wasAttributedTo <http://jeremytandy.me.uk/self#id> ;
      reg:status reg:statusStable ;
      reg:notation "c" ;
      .

reviewing the resulting registry entries:

action:

curl -i http://ukgovld-registry.dnsalias.net/def/letters2/_a?_format=ttl&_view=with_metadata

response (selected triples):

HTTP/1.1 200 OK
Server: nginx/1.2.6
Date: Thu, 21 Mar 2013 13:14:29 GMT
Content-Type: text/turtle
Transfer-Encoding: chunked
Connection: keep-alive

@prefix [...]

<http://ukgovld-registry.dnsalias.net/def/letters2/_a>
      a       reg:RegisterItem ;
      rdfs:label "A"@en ;
      dct:dateSubmitted "2013-03-21T13:11:01.801Z"^^xsd:dateTime ;
      dct:description "A (named a /ˈeɪ/, plural aes) is the first letter and vowel in the ISO basic Latin alphabet. It is similar to the Ancient Greek letter alpha, from which it derives."@en ;
      reg:definition
              [ reg:entity <http://ukgovld-registry.dnsalias.net/def/letters2/a> ;
                reg:sourceGraph <http://ukgovld-registry.dnsalias.net/def/letters2/_a:1#graph>
              ] ;
      reg:itemClass skos:Concept ;
      reg:notation "a" ;
      reg:register <http://ukgovld-registry.dnsalias.net/def/letters2> ;
      reg:status reg:statusSubmitted ;
      owl:versionInfo 1 .

<http://ukgovld-registry.dnsalias.net/def/letters2/a>
      a       skos:Concept ;
      rdfs:label "A"@en ;
      dct:description "A (named a /ˈeɪ/, plural aes) is the first letter and vowel in the ISO basic Latin alphabet. It is similar to the Ancient Greek letter alpha, from which it derives."@en .

Register /def states ...

/def a reg:Register ;
reg:containedItemClass reg:Register .

I would expect items that are not of type reg:Register to be rejected ... this is not the case.

file: myConcept-post.ttl

@Prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .
@Prefix dct: http://purl.org/dc/terms/ .
@Prefix skos: http://www.w3.org/2004/02/skos/core# .

Action:

curl -i -H "Content-Type:text/turtle" -H "Accept:text/plain" -X POST --data "@myConcept-post.ttl" http://ukgovld-registry.dnsalias.net/def

Response:

HTTP/1.1 201 Created
Server: nginx/1.2.6
Date: Sat, 02 Mar 2013 23:13:01 GMT
Content-Length: 0
Connection: keep-alive
Location: http://ukgovld-registry.dnsalias.net/def/_myConcept

The web UI confirms the existence of a new "member" in the /def register. This is an error.

When defined, the 'membership predicate' (e.g. ldp:membershipPredicate or reg:inverseMembershipPredicate) can provide additional validation.

If the ldp:membershipPredicate property has restrictions on range, then the members of the register must comply with this restriction.

If the reg:inverseMembershipPredicate property has restrictions on domain, then the members of the register must comply with this restriction.

As a point of note, we can also infer if the register should be classified as an additional 'type'; e.g. if reg:inverseMembershipPredicate is defined as skos:inScheme, then we can infer that the register must be of type skos:ConceptScheme.

etc.

Where the contents of existing code-tables are published via the registry, it will aid readability of the ordering of the list matches the order from the original code-table.

Currently I can't see any mechanism for explicit ordering of the register contents at present ... although it might work to order based on the register item's reg:notation property. In many cases for predefined code-lists the identifiers will be numeric, therefore I would expect these identifiers to be used for the reg:notation property which can then be used for ordering.

Hmm, such ordering might end up as: 1, 11, 12, 2, 3, 4 ...

Perhaps we need a specific numerical "reg:order" property that can be used for sorting. If not specified, this would default to the next number that is available. The property must be unique within the scope of a given register.

The _view=version feature of the API allows a client to see the separate version:Version/version:versionedThing resources for a given item.

However, the version triple representation is specific to one particular way to store versioning information in a triple store. We would like to be able implement a registry using other technology - e.g. a "nosql" document store or a hybrid of triple store (for the current world view) and document store (for historical versions). Exposing the internals of the versioning model in the API makes that harder (not impossible since the triple representation could be reconstructed from an alternate internal representation) but also sets an expectation that that's how things work.

In practice there seems no value to a client in having access to this view of resources. The primary use case is discover what early versions of an item are known and in any case we need a better API for that (see issue #14).

Proposed: remove support for _view=version in favour of _view=version_list with the latter only applicable to item views.

In the 2012-11-15 call we agreed that using named graphs is sufficient to handle both managed and referenced entity descriptions (given that Register and RegisterItem are versionedTypes).

In the wiki description and examples the presumption is that supporting registered entities as versionedTypes is an optional feature of the registry and not the default mode of operation. I'm not planning to support in the PoC.

In JMT notes the presumption seemed to be that general versionedTypes would still be supported.

Check whether there is a mismatch here and resolve if so.

Review the validation API

It is fairly minimal at the moment in that it just succeeds or fails but anything else seems to be duplicating the existing retrieval operations.