Resolve three issues on mailing list

Hi guys,

I think we could speed things up a bit by resolving three issues directly
here on the mailing list instead of doing so in the next call as I think we
already have consensus on them.


ISSUE-56: Specify how terms are treated when they are not specified in the
context
-----------------------

The basic question here is how we treat terms for which no IRI mapping is
defined in the context and that are not in absolute IRI form itself.

PROPOSAL: During compaction and expansion, non-JSON-LD properties are
dropped from the document body. All terms that don't contain a colon after
IRI expansion, are considered as non-JSON-LD properties.



ISSUE-74: Detail how IRI conflicts are resolved when compacting/expanding 
-----------------------

The question here is what happens during compaction when there are multiple
terms for the same IRI. In expansion we don't have a problem as all
properties' values are in array form anyway and we just add the colliding
values to such an array. The proposal in the issue and the way the
algorithms are specified at the moment is to choose the most specific term,
i.e., the one whose has the most matches for @type, @language, and
@container.

See: http://json-ld.org/spec/latest/json-ld-api/#term-rank-algorithm

I think we all agree that that is the way most people already expected
compaction to work. So the proposal is

PROPOSAL: In IRI compaction for each term mapped to the input IRI a term
rank is calculated depending on the @type, @language, and @container
mappings for the term matching the value of the property to compact. The
highest ranked term is chosen. If two terms have the same rank, the
lexicographically least is selected.



ISSUE-96: Should framing results be object or array
-----------------------

This is issue is about the return format of the framing method. The
discussed alternatives were: a) always return an array of objects, each
containing a context, b) always return an object containing a context and
the results within a @graph property, c) return a single object or an array
of objects depending on the number of results. Dave, Gregg, and I agreed on
option b) in the issue. So the proposal is:

PROPOSAL: The result of framing MUST be an object with a @context and @graph
property. The value of @graph is always an array containing zero or more
results.



I added the proposals to the issues so please vote directly there as it
makes tracking a bit easier:

https://github.com/json-ld/json-ld.org/issues/56
https://github.com/json-ld/json-ld.org/issues/74
https://github.com/json-ld/json-ld.org/issues/96


Cheers,
Markus



--
Markus Lanthaler
@markuslanthaler

Received on Friday, 27 April 2012 10:28:52 UTC