profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/rob-metalinkage/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Rob Atkinson rob-metalinkage Wollongong, Australia/Cumbria UK Distributed Systems, and more recently Semantics and Knowledge Architect. Contributor to open standards and open source implementations. @OGC @MapStory

rob-metalinkage/django-rdf-io 29

Simple RDF serialiser/deserialiser to support synching a django model with an external triple-store

RDFLib/profilewiz 5

A tool for doing things with Profiles

rob-metalinkage/django-skosxl 5

Django SKOS-XL Thesaurus manager

rob-metalinkage/django-gazetteer 3

A spatial gazetteer that harvests alternative placenames from uploaded data (and potentially django models) and consolidates into a single model.

opengeospatial/swe4citizenscience 2

An open citizen observatories repository on GitHub, to be used to develop SWE profiles for COBWEB and its sibling projects

rob-metalinkage/django-dataweb 1

A django project to manage semantic descriptions of web resources, using RDF vocabularies such as VoiD, RDF-Datacube, SKOS, DCAT etc

rob-metalinkage/CityGML-3.0CM 0

CityGML 3.0 Conceptional Model

issue commentopengeospatial/NamingAuthority

Simplification of CRS references/2: allow shorthand notation in addition to URLs

@rob-metalinkage the resolver service exists already for the URLs; the shorthand is not a URL.

We can define that notation specifically for coverages of course, but I though we see whether there is general interest as it is an overarching theme, so we brought it to OGC-NA. But if across our universes nobody else is interested we might pursue this for coverages only.

@ghobona WDYT?

pebau

comment created time in 2 hours

created tagInternational-Data-Spaces-Association/InformationModel

tag2021-06-24T17_24_23.557+02_00-nightly

The Information Model of the International Data Spaces implements the IDS reference architecture as an extensible, machine readable and technology independent data model.

created time in 2 hours

delete tag International-Data-Spaces-Association/InformationModel

delete tag : 2021-04-22T09_22_56.622+02_00-nightly

delete time in 2 hours

push eventw3c/sdw

Jeremy Tandy

commit sha 2b155337e46e8c588cf43017fa9880af03a1b300

more haste less speed. fixing presentation :-)

view details

push time in 3 hours

push eventw3c/sdw

Jeremy Tandy

commit sha cc1b46ea311aa9ca4c19d6a14e35b5a6e264144b

adding line breaks for readability

view details

push time in 3 hours

push eventw3c/sdw

Jeremy Tandy

commit sha 0e0b2341db25658e414d7203da41a228c0af2f24

Adding minutes and presentations for SDW-IG call 24Jun2021

view details

push time in 3 hours

push eventw3c/sdw

Jeremy Tandy

commit sha a6176d2d58218e88b307daa283016a75947da366

Adding Maps4HTML update presentation Peter Rushforth presented this at the SDW-IG plenary call, 24-Jun-2021

view details

push time in 3 hours

issue commentw3c/sdw

HTTP Redirect - with added semantics?

@BillSwirrl - at the SDW-IG meeting in May you said you'd try to collect your thoughts on this subject. Did you find any worth sharing? Thanks.

6a6d74

comment created time in 4 hours

push eventInternational-Data-Spaces-Association/InformationModel

JohannesLipp

commit sha 38119956dbbe74137c34fe18d15ae9593a463c26

Add comma to contributor listing

view details

push time in 5 hours

push eventInternational-Data-Spaces-Association/InformationModel

changqin26

commit sha f5e1497ae506728b17137e5694a134de8e22cc64

Replaced all subset_specification with idsc:JSONPATH/idsc:XPATH

view details

push time in 5 hours

issue commentw3c/sdw

HTTP Redirect - with added semantics?

Is there any interest from the SDW-IG in developing the "problem description" document?

6a6d74

comment created time in 5 hours

issue openedw3c/sdw

HTTP Redirect - with added semantics?

Problem summary:

The HTTP 303 redirect that's commonly used to relate real-world features to their digital counterpart(s) is a hack. There are no semantics conveyed - nothing to explain what information is conveyed by the resource you're being redirected to. But, it's the best of a bad bunch of options.

We often have many digital counterparts for a given real-world feature - each conveying different information, different semantics.

We typically use Content Negotiation (conneg) when resolving the URL for an information resource. That's fine if you want to choose GeoJSON instead of GML (e.g. choose the media type), but that doesn't help with semantics. There are typically many digital counterparts to a real-world object, each conveying different types of information.

Rob Atkinson (& co.) have long been working on the use "profiles" to characterise and describe the semantics of a domain-specific content model (?) that's encoded in a widely used data format.

But we can't use conneg to select by profile.

Finally, we still have issues around use of the canonical URI for the real-world feature. We often see people using the URL of the digital counterpart in their applications when they're intending to talk about the real-world thing itself.

So this often means that we're not sure that we're talking about the same thing or not. We need to make sure that applications are using the stable, canonical identifier to talk about a given resource.

An unsolved challenge is determining who's talking about (i.e. publishing information about) a given resource. We sometimes refer to this as "in-bound links". Search engines are beginning to use structured markup in information resources to pull together all information relating to a specific resource into a single search result. But there's no transparent infrastructure in place to support this kind of aggregation.

These challenges are commonly seen in the Augmented Reality (AR) world.

Given all of the above, information discovery and use tends to work in practice. Albeit with some offline/out-of-band schema sharing to provide the semantics for the information.

Proposals to remedy these challenges include:

  • A specific HTTP redirect code with semantics about the connection between physical and cyber domains (this would need liaison with IETF). The (S)ELFIE project proposed a new 306 Redirect "See Feature Description" HTTP code with specific semantics.
  • The OGC Disaster Pilot 2021 recommended use of a "switchboard" resource that keeps track of all authoritative descriptions of the resource, so that data users can find the information representation that's relevant to them. This may be an emerging practice in the Best Practice doc?
  • Content Negotiation by profile. Progressing conneg by profile would be an IETF task, see the recent discussion in the IETF HTTP API WG, e.g., https://mailarchive.ietf.org/arch/msg/httpapi/1OUzbFITjwXufIzJe6SKSXjdLfI/
  • Agreeing a best practice for a query parameter to select an information resource according to its profile type, e.g. "?_profile={my-profile}".
  • Engage with initiatives like schema.org to make it easier to aggregate information from multiple digital resources that are talking about a given real-world feature.

Next steps:

  • Write a SDW-WG paper / note to systematically describe the problem outlined above, essentially to articulate the cases where search / discovery is not working. By way of example, the Web of Things community did this in their Web of Things Discovery note: https://w3c.github.io/wot-discovery/.

Background information:

This topic has been discussed at two SDW-IG plenary calls:

created time in 5 hours

issue commentw3c/dxwg

Verify axiomatization of dcat:service

But after all, DCAT is primarily about data catalogs, so perhaps you should not expect dcat:service to a be a free-floating predicate that you can pick and use in a non-catalog context.

This is a very important statement which I agree with.

kvistgaard

comment created time in 6 hours

issue commentw3c/dxwg

Suggestion to add dct:format and dcat:mediaType to dcat:DataService

@jimjyang In Flanders we have create a DCAT profile https://data.vlaanderen.be/doc/applicatieprofiel/metadata-dcat capturing Open data, Geospatial data and closed data and standalone services.

When discussing data services this aspect has been kept as part of the endpoint description. So outside of the metadata that is collected in the DCAT catalogue. We observed that those technical details are very different depending from the ecosystem the data service has been designed in. Moreover many dataservices offer content-negotation so the actual syntax XML, json, etc is less important than knowing the business setting or the technical standards it follows. E.g. it is more important to know it is a OGC:WFS service than it is a service which returns XML.

Personally, I am when exploring a catalog of dataservices not interested in the actual data syntax format that is returned. As technical person I am more interested in what the kind of data that provided, it is easy linkable with other service, are there any shared identifiers in the data, etc. The technical format is just added to amount of work and libraries that have to be supported. Note that even if one has the same syntax their is no guarantee that one can connect the two services. So I rather consider the format for a dataservice as a low value property.

Looking into the future, we thought of constraints on the endpointdescription (e.g. SOAP WSDL description, Open API descriptions, ...) so that dataservice builders can use their native ecosystem documentation tools in such a way that generic metadata useful in the DCAT catalog context can be derived.
I personally do not think DCAT should replace the documentation practices in each ecosystem, but we should enable smart bridges between them.

jimjyang

comment created time in 7 hours

Pull request review commentInternational-Data-Spaces-Association/InformationModel

Feature/fdst41 extension

 idsc:AGGREGATE_BY_PROVIDER     skos:note "This action is always evaluated at the provider side."@en ; . +idsc:ADD+    a ids:Action ;+    rdfs:comment "This action modifies a number by adding a given value to it."@en ;+    rdfs:label "add"@en ;+    skos:note "This action modifies a number by adding a given value to it. The field to be modified and the given value are specified in the policy as idsc:SUBSET_SPECIFICATION and idsc:OPERAND, respectively."@en ;

The same change shall be applied to the definitions of other modify actions (divide, multiply, etc.)

changqin26

comment created time in 7 hours

issue commentw3c/dxwg

SHACL and DCAT profiling

@bertvannuffelen This is indeed annoying. Can this be raised as an issue for DCAT3? I would rather solve this on DCAT level than defining "EU dataset" which is not a dcat:Dataset and so on

bertvannuffelen

comment created time in 7 hours

Pull request review commentInternational-Data-Spaces-Association/InformationModel

Feature/fdst41 extension

 idsc:AGGREGATE_BY_PROVIDER     skos:note "This action is always evaluated at the provider side."@en ; . +idsc:ADD+    a ids:Action ;+    rdfs:comment "This action modifies a number by adding a given value to it."@en ;+    rdfs:label "add"@en ;+    skos:note "This action modifies a number by adding a given value to it. The field to be modified and the given value are specified in the policy as idsc:SUBSET_SPECIFICATION and idsc:OPERAND, respectively."@en ;

Thanks for pointing that out, already changed.

changqin26

comment created time in 7 hours

push eventInternational-Data-Spaces-Association/InformationModel

changqin26

commit sha 9f4f167dbda1787b00b75d8b85523d66893227a8

Changed the idsc:SUBSET_SPECIFICATION to idsc:JSONPATH/idsc:XPATH

view details

push time in 7 hours

issue openedw3c/dxwg

SHACL and DCAT profiling

Hi,

I have observed that the current explicit making Catalog a subclass of Dataset is hindering the usage of SHACL and also DCAT profiling.

The situation is as follows: in many DCAT profiles additional constraints are placed on datasets. And they are applicable solely to datasets in that catalog, not to the catalog entity. However by enforcing Catalog being a sublcass of Dataset and expressing this in the RDF representation natural SHACL profiling breaks.

Consider the following example profile:

  1. A catalog must have a title and a dataset
  2. An dataset must have as value for dc:accessRights http://publications.europa.eu/resource/authority/access-right/PUBLIC

The expectation from this profile is that the following example catalog is valid:

<http://example.com/catalog> a dcat:Catalog.
<http://example.com/catalog> dc:title "Example catalog"@en.
<http://example.com/catalog> dcat:dataset <http://example.com/dataset>.

<http://example.com/dataset> a dcat:Dataset.
<http://example.com/dataset> dc:accessRights <http://publications.europa.eu/resource/authority/access-right/PUBLIC>.

Unfortunately it isn't. According to SHACL the above RDF is invalid, because the ex:catalog has not a value PUBLIC for dc:accessRights.

It means that we have to redesign and introduce in any DCAT profile the notion of Datasets which do not have Catalogs as subclass in order to avoid the propagation of any constraint on a dataset to the catalog.

To test the case yourself: use https://www.itb.ec.europa.eu/shacl/any/upload with following content:

  • Content to validate: https://gist.github.com/bertvannuffelen/33849112b3aa66ce558f77a119ec81a4/raw/c47a27af0bb7db49ecb6ac62c814d5b576cc5931/dcat-profile-ex.ttl
  • External shapes: https://gist.github.com/bertvannuffelen/80422851bf44801f8493ab553b625374/raw/365f40d627e7da2ac7d4154022188597d61aa346/dcat-profile.ttl
  • External shapes: https://github.com/SEMICeu/DCAT-AP/raw/2.1.0-draft/releases/2.1.0/dcat-ap_2.1.0_shacl_imports.ttl
  • Load imports defined in the input? : check it.

The last 2 bullets are important: it loads the DCAT rdf file into the SHACL validator and then the error is triggered. If one does not load the DCAT rdf file, then it is all fine.

For a vocabulary which is aimed to be profiled this is a very annoying situation. Because in any profile one will add additional constraints on Datasets. I also do not know how do I express in a profile that the constraints on the dataset are not applicable to the catalog entity in that profile in the current setting without forcing the introduction of a subclass MyProfileDataset which is not a Catalog. Any suggestions?

created time in 8 hours

Pull request review commentInternational-Data-Spaces-Association/InformationModel

Feature/fdst41 extension

 idsc:AGGREGATE_BY_PROVIDER     skos:note "This action is always evaluated at the provider side."@en ; . +idsc:ADD+    a ids:Action ;+    rdfs:comment "This action modifies a number by adding a given value to it."@en ;+    rdfs:label "add"@en ;+    skos:note "This action modifies a number by adding a given value to it. The field to be modified and the given value are specified in the policy as idsc:SUBSET_SPECIFICATION and idsc:OPERAND, respectively."@en ;

@changqin26 Could you please change the idsc:SUBSET_SPECIFICATION to idsc:JSONPATH/idsc:XPATH in the notes of the modify actions too?

changqin26

comment created time in 8 hours

Pull request review commentInternational-Data-Spaces-Association/InformationModel

Feature/fdst41 extension

 ids:unit rdfs:subPropertyOf odrl:unit; ids:pipEndpoint a owl:ObjectProperty;      rdfs:label "has PIP endpoint"@en;      rdfs:domain ids:Constraint;-     rdfs:range xsd:anyURI ;+     rdfs:range ids:PipEndpoint ;      rdfs:comment "The reference to the endpoint which provides the current state of the feature of interest (as referrenced by the leftOperand) can be retrieved."@en . +ids:pipInterfaceDescription a owl:ObjectProperty;+     rdfs:label "pip interface description"@en;+     rdfs:domain ids:PipEndpoint;+     rdfs:range  xsd:anyURI;+     rdfs:comment "The reference to a URI that prodived the interface description of a PIP."@en;+.++ids:pipAccessURI a owl:ObjectProperty;

@clange @hosseinzadeha can you please review the UsageControlEndpoint.ttl in Contract folder?

changqin26

comment created time in 8 hours

push eventInternational-Data-Spaces-Association/InformationModel

changqin26

commit sha 7cd1a87650dbe9d97a9a4b6af166d711c72143c5

Added missing prefix.

view details

push time in 8 hours

push eventInternational-Data-Spaces-Association/InformationModel

changqin26

commit sha 8b415962a1660fd60f7e2b39b23cbe4546d73c73

Corrected indentation.

view details

push time in 8 hours

push eventInternational-Data-Spaces-Association/InformationModel

changqin26

commit sha fd4858c78d7d89a288b641e13c767630066ca74a

Corrected indentation .

view details

push time in 9 hours

push eventInternational-Data-Spaces-Association/InformationModel

changqin26

commit sha 7802cdc1b1b1ae4fe2aafef6f137aa9faa2d8e5a

Corrrected typos.

view details

push time in 9 hours

push eventInternational-Data-Spaces-Association/InformationModel

changqin26

commit sha be409754cc9bc147a296ada6c13f3aa84dcc5d45

Remove pip/pxpEndpoint to UsageControlEndpoint.ttl.

view details

push time in 9 hours

Pull request review commentInternational-Data-Spaces-Association/InformationModel

Feature/fdst41 extension

 idsc:DELAY a ids:LeftOperand ;     rdfs:comment "Delay the action. Use idsc:DURATION_EQ, idsc:LONGER, idsc:LONGER_EQ, idsc:SHORTER_EQ, or idsc:SHORTER with datatype xsd:duration."@en ; . +idsc:DATE_TIME a ids:LeftOperand ;+    rdfs:label "date time"@en ;+    rdfs:comment "To be used instead of idsc:POLICY_EVALUATION_TIME."@en ;+.+ # # ----------- idsc:EVENT a ids:LeftOperand;     rdfs:label "current event"@en ;     rdfs:comment "The feature dimension regarding whether current events are happening. Does NOT refer 'events' as in real-time data, sensor observations, or Complex Event Processing but rather as 'World Cup 2018' or 'Hannover Trade Fair'."@en ; . +idsc:HASH_ALGORITHM a ids:LeftOperand;+    rdfs:label "hash algorithm"@en;+    rdfs:comment "Indicate the hash value to be used, eg.SHA256."@en;+.  # idsc:STATE a ids:LeftOperand;     rdfs:label "state"@en ;     rdfs:comment "Specifies whether an (external) resource is true/false, active/inactive, has happened/not happened, etc. Operator must be idsc:EQUALS with RightOperands of datatype xsd:anyURI. The referenced URI should point to a (remote) resource which returns a xsd:boolean value."@en ; . +#+idsc:SUBSET_SPECIFICATION a ids:LeftOperand;+    rdfs:label "subset specification"@en ;+    rdfs:comment "Specifies which modification method is applied for data. Operator must be idsc:EQUALS with RightOperands of a jsonPath,xmlPath or rdfPath."@en ;

I replaced “idsc:SUBSET_SPECIFICATION” with “idsc:JSON_PATH” and “ids:XPATH”, please review.

changqin26

comment created time in 9 hours

push eventInternational-Data-Spaces-Association/InformationModel

changqin26

commit sha 7c7e481c3cdb8e755bbaaeaea88d69339fa8c359

Replace SUBSET_SPECIFICATION with JSON_PATH and XPATH.

view details

push time in 9 hours