rdf-ext-archive / discussions Goto Github PK

http://nvie.com/posts/a-successful-git-branching-model/
https://de.atlassian.com/git/tutorials/comparing-workflows/centralized-workflow

From @betehess on January 25, 2015 23:32

Sorry, this is not exactly an issue but I didn't know where to ask those questions.

First, just know that I am mostly a n00b with Javascript. More exactly, that I don't have any experience with Node.js, nor with JS libraries relying on some Node.js toolchain.

First, I am not sure where to find the main rdf-ext.js library. I guess it's not that one? Do I need to build the library myself? How?

I have the same questions with the dependencies. For example, the README mentions N3.js. But I don't see it anywhere under lib. Do I need to pull manually that dependency? How do I know about which version is supported? What about the other files under lib?

About the documentation: I have seen http://bergos.github.io/rdf-ext-spec/ and I think I can read WebIDL. But in the example you added today, you used parseTurtle, which I don't find in the main specification. I guess it's somewhat related to DataParser? In any case, I am mostly interested in RDF parsers that can eagerly react on triples instead of the complete graph if that's available (we have our own Graph implementation in banana-rdf). Maybe it's the ProcessorCallback thing? I couldn't find its definition in the spec.

At this point, I would appreciate a few notes on how to get started with rdf-ext in the browser, with the examples you just added, and starting from a blank project. Thanks again for everything: I really want to use rdf-ext from banana-rdf :-) To get an idea of what I am doing, you can look at banana-rdf/banana-rdf#219 .

Copied from original issue: rdf-ext/rdf-ext#16

Some stores may have a default graph, like the SPARQL store. Methods like .graph or .match require a IRI parameter for the named graph. What value should be used for the default graph? null is already used for any graph. true would allow to check if the value is set and it's not a string or RegExp object. Are there any reasons to not use true? Could it be handled in a different way?

https://www.w3.org/2011/rdf-wg/wiki/Graph_Terminology#Visual_Diagram

so far i've seen LDF servers implementing Memento
https://github.com/LinkedDataFragments/Server.js/wiki/Configuring-Memento

From @elf-pavlik on November 26, 2014 15:16

I found email where @danbri mentions it back in 2007
http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2007Aug/0170.html

I would find it super useful where I care mostly about providing JSON-LD but can also automatically serve RDFa for various crawlers

Also some existing python package: https://github.com/alexstolz/rdflib-rdfa-serializer

If this works out we could also try to make one for Microdata...

Copied from original issue: rdf-ext/rdf-ext#10

Just some ideas....

HOWTOs for implementatin provider:

• How to write a parser/serializer
• How to write a backend

HOWTOs for users:

• How to parse a graph and get the properties of a resource
• How to copy a graph from one store to another
• How to modify a graph

What is the plan for Microdata parsing in RDF-Ext? rdf-parser-microdata appears to be deprecated and no longer maintained.

I want to consume Schema.org data from a number of websites. While some of it is in JSON-LD a large portion of it is in Microdata.

I think having to pass null arguments as in

N3Parser.parse($("#data").text(), null, window.location.toString()).then(

is quite ugly. Wouldn't it be good to get rid of those as soon as possible?

At the moment it's difficult to find all informations about RDF-Ext. A organization page could be used as landing page. The page should contain the following informations:

• everything the rdf-ext README.md contains
• link to the rdf-ext CONTRIBUTING.md file

The package list should be maintained only on the organization page and removed from the readme.

The global rdf class should be the convenient main entry point of the API and allow access to the most commonly needed RDF specific functionality.

Some thoughts:

What should stay:

• factory method for creation of nodes and triples
• factory method for creation of graphs
• factory method to create datasets (quad stores)

What should be removed:

• prefixMap/prefix resolution: This should go to a CURIE library as not RDF specific: there are no prefixes in RDF (even though some concrete syntaxes support CURIEs and similar mechanism)
• encodeString: not RDF specific
• AbstractGraph: this is a utility for service provider, rdf should be the entry point for API users
• Triple class: users should create triples via factory method, unclear what the benefit is of having this visible

What should be added:

• methods to get serializers and parsers and/or to serilaize and parse: serializing and parsersing are very frequently needed functionality so it should be available directly from the main API access point. Of course, everything offered at this level is independent of any concrete format, it simple provides an extensible way to get/use the available parsers and serializers by specifying the desired format (of course, using media types as the standard mechanism for identifying data formats), see also: rdf-ext-archive/rdf-formats-common#1

The discussion is open....

From @bergos on September 5, 2015 22:23

• create modules for all parsers and serializers
  • create module for JSON-LD parser
  • create module for JSON-LD serializer
  • create module for Microdata parser
  • create module for N-Triples serializer
  • create module for RDF/XML parser
  • create module for SPARQL update serializer
  • create module for Turtle/N3 parser
  • create module for Turtle/N3 serializer
• create modules for all stores with new interface
  • create module for in memory store
  • create module for SPARQL store
  • create module for LDP store
  • create module for file system store
  • create module for single graph store
  • create module for abstract store
• create module for Clownface
• add documentation
  • for abstract parser
  • for abstract serializer
  • for abstract store
• implement distribution builder

Copied from original issue: rdf-ext/rdf-ext#46

With this commit I removed the command line tool from the rdf-ext package. The code uses the old interface and it was already planed to use a separate module for this tool.

The JSON-LD parser module, based on AbstractParser, implements a new API. If we can agree on the new API I will create modules for all other parser, currently bundled with RDF-Ext.

Promise process (any toparse, optional ProcessorCallback callback, optional DOMString base, optional TripleFilter filter, optional SuccessCallback done)

.process returns now a Promise object. For asynchronous parsers the boolean value was useless anyway. Both, done and Promise.resolve, are called. done can be null. toparse can be a Stream. The parser detects if the toparse value is a Stream object. The rest works like defined in the RDF-Interfaces/RDF-Ext spec.

Promise parse (any toparse, optional ParserCallback? callback, optional DOMString base, optional TripleFilter filter, optional Graph graph)

Also .parse returns now a Promise object like .process. Both, callback and Promise.resolve, are called. callback can be null. toparse can be a Stream. The parser detects if the toparse value is a Stream object. The rest works like defined in the RDF-Interfaces/RDF-Ext spec.

ReadableStream stream (Stream inputStream, optional DOMString base, optional TripleFilter filter)

The .stream method is new. The data, end and error event is used. N3.js uses also a prefix event. This is currently not implemented. Do we need this? Everything else works as usual.

Can rdf-ext make distinction between a Dataset and a Graph?
https://github.com/rdf-ext/rdf-ext-spec/blob/gh-pages/API.md#graphoptional-arraygraph-other

Graph could represent a simple named or default graph and only contain Triples
Graph could provide simple access to it's name
Dataset could represent multiple graph and contain Quads

Currently Store seems very close to Dataset
https://github.com/rdf-ext/rdf-ext-spec/blob/gh-pages/API.md#store

But parsers like Trig, JSON-LD, N-Quads shouldn't return Store IMO

This would ensure every tagged version that passes the tests gets deployed and that only tagged versions are deployed.

From @bergos on June 24, 2014 22:13

Create a RDF-Ext Store implementation which caches graphs in memory or Web Storage and manually forwards changes to another RDF-Ext Store. Offline Web application features can be added very easy this way.

Copied from original issue: rdf-ext/rdf-ext#2

Hi,

I have written an RDF/XML serializer for rdf-ext. Please find it at http://github.com/kaefer3000/rdf-serializer-xml . I would be happy to transfer it to the organisation or have it included in rdf-formats-common.

Cheers,

Tobias

The distribution builder should use browserify to create browser distributions. It should include a command line and web interface.

It's already work in progress...

#0.3.0

Version 0.3.0 contains many changes, but should require only minimal changes in the code to be 0.2.x compatible.

Changes

• more modular approach with separate npm packages
• RDF-Ext distribution builder to build browser distributions and custom builds
• no RDF-Interfaces library required
• parsers, serializers and stores are no longer attached to the global rdf object
• rdf-ext returns the rdf object and longer a init function

Dates

• 2015-12 release candidates
• 2016-01 release
  #1.0.0

Version 1.0.0 will implement the interfaces defined by the RDFJS Representation Task Force.
This will require changes in libraries that use the low level interfaces such as parser, serializers, stores and object to graph mappers.

Changes

Dates

• 2016-02 - create branches for 1.0.0
• 2016-03 - beta tests
• 2016-04 - release candidates
• 2016-05 - release

The mime type utils are only usefull when many parsers and serializers are registered. To remove the dependencies from the rdf-ext package, the code should get it's own package. Any proposals for a package name?

We need support for filtering out literals which are not one of the preferred languages.

• just provide literals of a specific language: useful when you want to select a specific language only
• filter based on a list of preferred languages. As an example I would like to have de > en > no language tag: often what you would display in the real world because a non-translated resource is better than no resource

In both cases I would not get back more than one s-p-o triple back where there were multiple languages available.

I think I would like to have that on graph level so I can work with a graph in the UI which does not provide more than one literal to show for the same thing.

Should it return success == true when something has been deleted? or should report an error if something was not? (avoiding using success)

If the context of a JSON-LD file contains prefixes add them to the prefixes of the store

for an older version:

// load prefixes of data elements
var context = data['@context'];
$.each(context, function(key, value) {
	if (typeof value == "string" ) {
		if(value.slice(-1)=='#' || value.slice(-1) == '/')
			rdf.prefixes[key] = value;
		}
	}); 

From @bergos on August 21, 2015 23:31

We should define an parser/serializer API to stream Triples. The N3.js library would support that feature already.

Copied from original issue: rdf-ext/rdf-ext#43

• implement RDFJS Representation Task Force spec
  • core (Terms, Quads, Graphs)
    • Data Model
    • Dataset
    • Stream Interfaces, (Source, FilterStream)
  • parsers
    • JSON-LD
    • Turtle/N-Triples
    • RDF/XML
  • serializers
    • JSON-LD
    • Turtle
    • N-Triples
  • stores
    • rename LdpStore to WebStore and use rdf-fetch
    • SPARQL
    • Dataset (replaces in memory store)
  • formats
    • common formats
    • html formats
  • others
    • rdf-fetch
    • clownface
    • simplerdf
      • simplerdf-fetch
      • hydra-fetch
• replace request with fetch (incl. polyfill)

Optional:

• implement indexed dataset
• port LDF query engine to RDFJS interfaces

What should have stream?

• graphStream
• matchStream

Everything that has a GraphCallback at least should have a stream method (store only),
discuss

We should write down a small guideline how to contribute to RDF-Ext. Here are my ideas and proposed directions:

• Style Guide: JavaScript Standard Style
• Tests: All packages should have tests with 100% coverage. Do we define a default test framework? At the moment only mocha is used.
• Paches: All developers (including members of the organisation) work in their own fork and send patches as pull request.
• Merge patches: The patch must pass all tests and X members of the organisation must accept the pull request.

We can't get there immediately. Till release 0.3.0 we should allow to break rules without further discussion.