-
Notifications
You must be signed in to change notification settings - Fork 71
November 9, 2016
This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join. Here is the info:
- Time: 1:00pm Eastern Daylight Time US (UTC-4)
- Dial-in Number: (641) 715-3570
- Participant Code: 304589#
- International numbers: Conference Call Information
- Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
- IRC:
- Join the #islandora chat room via Freenode Web IRC (enter a unique nick)
- Or point your IRC client to #islandora on irc.freenode.net
- Nick Ruest
- Natkeeran Ledchumykanthan
- Kim Pham ⭐
- Don Richards
- Bryan Brown
- Amanda Lehman
- Tom Shorock
- Diego Pino
- Danny Lamb
- Mark Cooper
- Aaron Coburn
- Jon Green
- Melissa Anez
- Follow-up on last week's pull requests
- How do we create resources based on JSON-LD?
- ... (feel free to add agenda items)
https://github.com/Islandora-CLAW/CLAW/pull/408
Ubuntu
- Nick: Based on testing, seems good to go.
Solr
- Danny: still in progress
https://github.com/Islandora-CLAW/CLAW/issues/410
Danny:
- Ticket came out of a conversation for past couple weeks, spinoff from API ticket https://github.com/Islandora-CLAW/CLAW/issues/398
- About POST, JSON-LD docs to an endpoint, that is not enough information to actually create a Fedora resource in drupal that you will need to know not just entity type but its bundle. Those are not in JSON-LD. If they are, they come from Drupal endpoint to local domain, does the thing where everyone in Islandora needs to host their ontology for all of their stuff even though we all use the same one as per Islandora can't put in JSON-LD
- So for example in figuring out if want to make an image or collection, investigated options to do this
- There is not a clear cut winner. Some consequences
- Options:
- Use JSON-LD serializer, receive JSON-LD tell serializer to make a certain entity of a certain bundle
- Could do a couple of ways
- Do a reverse lookup of rdf mappings and do an sql query find one that matches all rdf types matching in the JSON-LD
- Nothing magical, everyone provides an event response, a filter pops saying that this JSON-LD that was analyzed meets these criteria and i know i'm going to make an image or collection
-
Fallout: if you have the hooks, it means that someone going through the UI making a new bundle and putting fields on it they would not be able to use the REST API, it would be broken until that hook or event listener gets implemented
-
Do we want people who are site builders to have this ability? do we care? do something more develoepr friendly or flexible or do something more simple or limiting, have exact match of rdf:types
Aaron: you could use an OWL restriction, if you have a set of restriction classes defined, POST your JSON-LD says OK i see that this conforms to the following three different content types, or maybe it doesn't conform to any of them as a user you have to decide or tell the system OK of those 3, pick this one
Danny: reason I'm shying away from OWL is because we don't know a way with PHP how to use it and do structural typing with is
Aaron:
- Could create a simple service, pass a JSON-LD document and that returns a list of types
- Doesn't need to be in Drupal or PHP, could be a service
Danny: yes an option. Diego is manually parsing XML?
Diego:
- Yes using a simple service, converts owl 1 and 2 restrictions into business rules
- Written in php, implemented for two years, works. Depends on you building your own ontology, in 8.x-1 ontology datastreams have ontology objects. It is not site builder friendly. On the other side if POST a wide Islandora ontology, you're imposing internal way of mapping stuff.
- Doesn't allow you to POST multiple real ontologies in real world, RDF for interoperability. Don't want to use schema book want to use another ontology.
- If we could do have mapping user interface simple for entities, then an external view, that would be a way to empower the site builder, the Drupal promise.
Danny:
- We should push as much as we can out to the site builder, but fear by building a UI it's not going to work for everyone. We could work it so that it's flexible but wondering if all of that work worth if or compare to an ontology or use rdf mappings and look them up in rdf mappings.
- Third option: a UI that would let people do it
Diego: Something like the original idea that API-X had in terms of matching, LD Path, or some type of RDF querying algorithm that matches a pattern inside the RDF itself, not using the restriction inside. Going that way we'd need to build a drupal ontology, with classes that define what our resources inside. Each new modules will have new entities, which will need to be mapped inside the ontology again. Dream of master islandora ontology to serve all users will be a failure.
Danny: I don't think everyone needs to make their own ontology. We'll have users that won't make one. Aaron's approach is most flexible, make it a separate service. Make everything a small separate service where if you knew what you were doing it and wanted to change it you could. Not sure what the best implementation is. Can do exact match where all your rdf:types need to be contained in a JSON-LD doc.
Diego: Less effort attempt intitially by defining an interface, in PHP. Implementation that matches rdf:type that matches back to content types, but then allow some type of dependency injection or replacement to add a more complex pattern. Could have a reasoner or service whatever you want to process the json and come to a solution. We as a small CLAW group develop an rdf:type to content type mapping.
Danny: We get that for free with mapping, bundle
Diego: Yes and for bundles, hooks and sub hooks that matches an object to a list of rdf types. Then make a simple solution that matches a few or many and run it. Leave space for implementation, interfaces to swap with something fancier more suited to work with semantics. What aaron said to but your own ontologies and making your own mapping without imposing it. e.g. bryan using SKOS solution packs with diff needs
Danny: as a service but base off of rdf mappings we get by default
Diego: only thing i feel is missing, an extra ontologies to rdf mapping. right now rdf UI only allows schema to work. or add rdf:type using code. as a community project if we could add something new there, a ui change. some templating then empower that interface for our testing
Danny: right now fine with the yaml, waiting for someone like you to suggest such a thing and then we'll do it. If stakeholders are interested to control our mapping as it flows through our system to create new objects for JSON-LD documents
Nick: can we have someone to solicit for use cases?
Kim volunteered
Nick: timeline is 2 weeks, until the 25th of November
Danny:
- Discussion of #410 spawned from issue https://github.com/Islandora-CLAW/CLAW/issues/398
- The issue is with Drupal's content negotiation, does not properly respect content
- If we want to have a really nice REST API that has analagous HTML pages that would be like the forms for the same kind of operations for POSTing, but that's not going to happen with Drupal 8
- We could separate it out, /islandora/rest gives you data and we could make forms
- but if we wanted to do something like a view, like a child ldp:contains or query for all the things that fedora:hasParent on this one object, if you want that and get the same list in JSON-LD and same endpoint and use content negotiation then it's not going to work
- at least not with drupal 8.x-3 not released for another 6 months - which is a big problem
- our options then are either we ditch views/REST export, take power away from site builder, do all queries ourselves in code, not the end of the world but doesn't give site builder much control
- or then we tackle the content negotiation beast head on, or split it. REST API sends down the wire, don't ask for html do it elsewhere any thoughts or work on something and get feedback after?
Diego:
- some ideas, but for getting fedora resources should go your path ~~~
- REST endpoint for custom entity, it worked but it's not only Drupal but Symfony, imperfect
- if you can come up with a simple solution, idea of how to make it work, work around that, even possible to forget about a REST module and use a custom endpoint for that
- REST depends on use, too much machinery in between
- Full symfony can bypass completely and rely on endpoint in drupal that doesn't use the REST API provided by drupal
Danny: kind of OK with that
Diego: we still have simple use case, no variety of diff backends. just fedora 4, drupal, need to put stuff inside. if we can make it work custom specific to JSON-LD drupal stuff then it will work for me
Danny:
- don't see a problem with that, looking for feedback
- use symfony stuff. no sure how well views plays into it, as a block then render it out as a rest export, so there's not duplication and site builders can still control what fields come back
- or say forget it, manual sql query for stuff and spit out a list. or just teaser view
- in drupal 8 views
- html make your view typical one
- also has a REST export, view is a page or block, also a rest export, the export will spit it out based on the serliaizer you tell it
- REST export functionality issue is that it deosnt play well with each other at all. html json, just get json all the time
- never will see the html
Danny:
- yes and doesn't respect the _format stuff
- so the only situation where i can see a problem if we just take the power back the problem i see is that we could be querying one way, and then someone else can make a View that would do the same thing but then play with the query by accident
- make a View can't touch the query part or display part of it
- if we do our own thing bypass all of that but someone might try to replicate a view that doesnt work
- expose to UI too much gets exposed etc. Site builders having to work with SQL
Amanda: i want to ask what currently do that you won't do in the future. custom views will interact/mess up the REST stuff?
Danny:
- no, we can't use the way drupal wants you do things to build the API. site builder will be able to make Views, in the end content is Drupal entities and use fields whole ecosystem. that is possible, doing this will not make that impossible. The problem is if I want to use that method to build the API, it's not going to work. Every get request in the API could and should be implemented as a View, but I can't because drupal doesn't understand content negotiation, gives you the wrong format. Views functionality as it stands in Islandora will still exist
- if the core API was developed as views, then that woudl give interested parties the ability to have a lot of flexibility, change things to suit their needs without a developer within core api. e.g. how members of a collection are viewed, you could not have that if i don't do it as a view
Amanda: It's already a cool program, if you're asking for flexibility for the site backend then they can have a developer
Danny:
- trying to nail down what this core api will provide, what will you get bare bones fedora, basic CRUD, see children in LDP tree
- need to expand to include collection membership and file ownership but that needs to be done first
You may be looking for the islandora-community wiki · new to islandora? · community calendar · interest groups · roadmap