Requirements

[l00mi]

Lets collect "high-level" requirements on a Data Exploration here.

[l00mi]

• Let users explore the data structure:

  • per endpoint ?
  • per namespace (domain) ?
  • per named graph / set of named graphs?

• It should be accessible also for people without intimate Linked Data knowledge.

[BenjaminHofstetter]

What Things are in this data?

This is what is happening before the question "how are the things connected". Like an overview of things (Classes)

• classes
• class hierarchy (maybe not even that)

Why: If I am lucky there are Classes like Person etc. This helps me a lot to understand what is going on.

[martinmaillard]

I'm not sure I understand. Isn't that already what we are showing?

[mchlrch]

Maybe @BenjaminHofstetter meant a view that just shows a listing of the Classes, without showing attributes and links?

For lobbywatch that would be something like:

• dbo:MemberOfParliament
• schema:Person
• lobbywatch:BusinessSector
• org:Organization
• lobbywatch:Mandate
• ...

[BenjaminHofstetter]

Yes this is exactly what I mean.

[martinmaillard]

I see. That could be useful. I was just thinking: wouldn't it be better to implement this directly in Trifid?

[martinmaillard]

FYI there is now a list of classes :)

[BenjaminHofstetter]

Properties

What properties do we have. And what are the combinations do we have. Like domain and range in owl or what appears in the subject or object position.

subjects (types) | predicate             | Object types 
--------------------------------------------
Person             example:name              Text 
Product 
Pet 

Why: it helps me to understand the properties and how they are used.

[mchlrch]

I would like to be able to declare multiple predefined Viewpoints for the datasets that I create, in order to allow the user to select one of the viewpoints for display. The Viewpoint declares which shapes/classes are rendered.

If I don't have shapes declared explicitly and the shapes get derived on the fly, then I would like to be able include the relevant rdfs:Class es in the Viewpoint

Pseudo-Turtle:

[] a :Viewpoint ;
  rdfs:label "Economical classification" ;
  rdfs:comment "Elements that are used for the economical classifications of permits" ;
  :includes ex:Permit
  :includes ex:Sector ;
  :includes ex:Profession .

[] a :Viewpoint ;
  rdfs:label "Agencies and TERMDAT integration" ;
  rdfs:comment "Elements that are used for agency association, including Termdat integration" ;
  :includes ex:Permit ;
  :includes ex:GovernmentOrganization ;
  :includes ex:DefinedTerm ;
  :includes ex:DefinedTermSet .

Presenting the Viewpoints in a dropdown list similar to the dropdown list of the named-graphs would make sense.

[bergos]

@mchlrch I would propose to use a more generic concept of just defining sets, which can be given as arguments to SPEX to include/exclude all classes of the set. Later we can have a look again on the Viewport concept, also with more focus on the visualization (e.g. positions, zoom level).

schema:CreativeWork could be used as container and schema:hasPart as property to point to all items.

The implementation could be approached in multiple steps:

• add exclude & include arguments in the URL to point to the sets
• add UI to manage which sets are used and update the URL for sharing
• add UI to write sets

[mchlrch]

To clarify, my requirement is only about controlling what is displayed and not about how it is displayed or layed-out. These are separate requirements IMO

[martinmaillard]

I understand @mchlrch's suggestions and that is doable. Although we would need to define a way to find these viewpoints (should they be part of the .void/... thingy?).

@bergos I don't really understand your remarks. What is that advantage of using something very generic like CreativeWork and hasPart? I'm also not sure we can put everything in the URL: we will hit the limit quite fast if we list all the classes to show in there.

[mchlrch]

Although we would need to define a way to find these viewpoints (should they be part of the .void/... thingy?).

I think so, part of the .void/... alongside the shapes. This would be the case, when shapes and/or viewpoints are published together with the dataset itself.

Feeding via URL param would be useful during development and to have personally customized viewpoints. But I do understand the concern with the limit. Maybe it would be an option to have a config lookup: Have a URL param that allows to pass in a URL value and have spex dereference that to read the config. This way, a developer could have the the config locally with trifid in front.

[bergos]

@martinmaillard My idea was to pass URLs of the include/exclude sets to the app, not the classes or the whole set, just like @mchlrch described it. If you want to use a class for the set, it would be schema:CreativeWork, but I would not even write it into the data. A document like this should be enough:

<#include>
  schema:hasPart <Person>, <Woman>, <Man>, <Camera>, <TV>.

[mchlrch]

I would like to be able to declare which classes are stereotypes in order to either show them as stereotype markers on a class or alternatively hide them in the rendering.

For example I would like to declare skos:Concept as beeing a stereotype in the following:
https://zazuko.github.io/SPEX/#/?url=https%3A%2F%2Fseco-bdb-integ.zazukoians.org%2Fquery&graph=https%3A%2F%2Flinked.opendata.swiss%2Fgraph%2Fseco%2Fpermits-economy&prefixes=lobbywatch%3Ahttps%3A%2F%2Flod.lobbywatch.ch%2F&prefixes=wdt%3Ahttp%3A%2F%2Fwww.wikidata.org%2Fprop%2Fdirect%2F&forceIntrospection=false

Example data sample https://permits.zazukoians.org/professions/220:

• the type is https://permits.ld.admin.ch/schema/Profession
• the stereotype is http://www.w3.org/2004/02/skos/core#Concept

<https://permits.zazukoians.org/professions/220> a <http://www.w3.org/2004/02/skos/core#Concept> , <https://permits.ld.admin.ch/schema/Profession> ;
   <http://www.w3.org/2004/02/skos/core#prefLabel> "dentista"@it , "Dentist"@en , "Zahnarzt/ärztin"@de , "Dentiste"@fr ;   <http://www.w3.org/2004/02/skos/core#notation> "220" ;
   <https://permits.ld.admin.ch/schema/code> 220 ;
   <https://schema.org/position> 2 ;
   <http://www.w3.org/2004/02/skos/core#broader> <https://permits.zazukoians.org/professions/200> ;
   <http://www.w3.org/2004/02/skos/core#inScheme> <https://permits.zazukoians.org/professions/scheme> ;

See also: https://en.wikipedia.org/wiki/Stereotype_(UML)

[bergos]

The sets proposal could solve this by using one set just for stereotypes.