ukgovld / ukl-registry-poc Goto Github PK
View Code? Open in Web Editor NEWWorkspace for design of UKGovLD registry proof-of-concept
License: Apache License 2.0
Workspace for design of UKGovLD registry proof-of-concept
License: Apache License 2.0
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
I tested to see what would happen if I patched an entity to add an additional french translation of the description property.
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
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.
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.
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.
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
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.
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?
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:
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
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.
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 ...
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 ...
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.
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;
.
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
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!)
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
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
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.
[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 .
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.
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@.
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.
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.
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
.
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" .
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
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 ...
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
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
SELECT ?p ?o
WHERE {
http://ukgovld-registry.dnsalias.net/def/numbers/_nine:2 prov:wasAttributedTo ?o .
}
returns zero results.
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 .
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
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.
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.
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):
Note that the same argument applies to 'dateOfLastChange' (from ISO 19135:2005) ...
Proposal (B):
A request for a specific version of register item returns:
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
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 ;
.
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):
water quality impacted by heavy rain ...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
Need a robots.txt configuration. Currently being hit by googlebot. Plus need to block baidu and setting nginx throttling
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.
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.
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.
Review the search API
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
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 ;
.
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)
Syntax for _versionAt={datetime} has not yet been discussed
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.
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 .
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.
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 ;
.
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:
Is this problem because the web-UI does not know about the bufr4-core ontology?
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
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.
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.
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.
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
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.
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
Requestor IP address is not being logged correctly in the Registry level logs (is present in proxy logs). Despite use of x-forwarded-for.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.