Consider obsoleting use of blank nodes for properties and "generalized RDF" #37
Comments
Do we actually see this "bnode as property" form used in practice? I can't recall seeing an example, but I haven't seen all that much JSON-LD. |
|
@gkellogg could i request an example? I don't actually understand how the feature would be used? Is this what you mean: :fred _:b0 :barney .If so, i don't understand what that would mean and how it would be used practically speaking.... |
|
@pjohnston-wiley To my (possibly-wrong!) understanding, the issue is that what you show could be written down using JSON-LD 1.0. We are talking about making it illegal in JSON-LD 1.1, because (as you no doubt knew when you wrote it) it's not legitimate RDF 1.1. @gkellogg Do you think this might be a place to "report forward" to a potential future RDF WG? I don't think that we would have much to say absent any substantive examples. |
|
@ajs6f if that is the case, then i'd totally be supportive of keeping it out of JSON-LD 1.1, but i don't have the history of whether it is possible just because nobody thought to prevent it, or somewhere or another in the mists of time there is/was a legitimate use for it. |
|
@pjohnston-wiley Sure, that's exactly why I was asking after examples. |
|
@pjohnston-wiley Yes, the ability to create properties as blank nodes was a "feature" of JSON-LD 1.0, and RDF 1.1 created a Generalized Dataset feature, specifically so this could be allowed. The idea was that some JSON developers may not be keen on creating and maintaining vocabularies, and allowing a property to resolve to a blank node would some how make this easier for them, but these blank node identifiers don't survive some of the algorithms, specifically Flattening and ToRdf, and are really of dubious value, IMHO. @ajs6f Don't know what we would report to a future RDF WG; there are other reasons for Generalized Datasets, and there may be some use cases for blank node properties, but these aren't really explored in JSON-LD. I'm not aware of any use of this feature in the wild, and obsoleting/removing it in 1.0 could go against our charter, but not sure where the harm is done. A Common Crawl search might be able to find something that uses it, but I doubt it, as they're really not useable for anything other than a source syntax. The use cases for blank node properties are better handled by document-relative IRIs. |
|
The only place I heard of where bnodes as predicates appear are very technical: there are some more complex OWL deductions where, for "intermediate" steps (if described in terms of triples) they become necessary. To be honest, I do not remember the details, but I would think they are related to terms like inverse properties (where we would say "there is a property that is the inverse of property p"). However, I do not think it is relevant for us. First of all, OWL reasoners rarely (if ever) use RDF as a formalism internally, and serializations like JSON-LD or Turtle are there to encode the data, not the deductions. |
|
@gkellogg I guess that would be the report-- that JSON-LD 1.0 made it possible to write down generalized datasets, and no one seemed to care. 🤷♂️ |
|
Proposal: Add an editorial warning to the 1.1 specification that the use of blank nodes as predicates is possible, but that it is deprecated and recommended for removal in a hypothetical JSON-LD 2.0 |
|
👍, especially since we have yet to come up with an example (unless I missed it in the conversation). |
|
-1, for the following reasons:
What am I missing? |
|
Thanks for the feedback Manu :) To your points...
The new evidence that would overturn the resolution is showing that two organizations are independently using this feature. If it's important, then after 5 years of JSON-LD 1.0, there must surely be two independent uses in the wild? Could you point us to some please? And again, it's not being removed (that would be a breaking change, which we are indeed not empowered to do), it's being flagged as likely to be removed from the specification in the future unless there's evidence at the time to suggest otherwise. |
Document-relative terms support the same use case. This was raised by Kingsley, as he often uses them in his examples and couldn’t in JSON-LD. We added “@vocab”: “” to cause the vocabulary base to be taken as the same as the document base. See json-ld/json-ld.org#488.
There’s a pretty strong desire by the WG to allow them to be more fully aligned. The primary obstacle to this was the use of Blank Node properties, which the document-relative terms satisfy. There was no known use of this in the wild, but in any case, the proposal doesn’t remove the feature, just marks it as Obsolete, which indeed, it is. 1.0 documents will continue to work, and 1.1 processors should continue to handle these, but the use is discouraged. The RDF WG did something similar for Reification, IIRC. There’s a good reason to be able to say that the JSON-LD datamodel is the RDF datamodel, at least formally. Yes, the JSON syntax forms it’s own effective datamodel, but by obsoleting those elements that prevent it from directly corresponding to the RDF datamodel we form a better basis for JSON-LD. IIRC, it was blank nodes as properties that required us to say it is a generalized RDF Dataset, and not simply an RDF Dataset. Going back to the motivations for allowing blank nodes as properties was an effort to allow easy adoption of JSON-LD by developers not prepared to create vocabulary IRIs to resolve them to. The document-relative term resolution solves exactly the same case, and is consistent with other RDF usage from other syntaxes. |
|
The resolution on the WG call of 2018-09-07 was to mark the feature as "obsolete" meaning that it is still valid for use, but not likely to persist indefinitely. Marking as editorial before we can close. |
|
I have found the tools I think to show how this ties into RDF Semantics, and find out if there are any real problems with it. So ping me when you get back to this. :-) |
|
@bblfish its in my editor’s queue, it would be great to put down any thoughts you might have. @iherman mentioned some internal use of nodes as predicates for OWL, but no other concrete syntax supports this. The main issue the WG needs to consider is if any code in the wild depends on specific blank node labels for properties, as well as those generated via flattening in non-predicate locations. Note that obsoletion is not deprecation, so they remain valid, but the text will change to make them less prominent. |
|
@azaroth42 wrote:
I just looked into this... we don't. It requires the markup to be changed to something like "#foo" instead of just using "foo". So, we're back to RDF doesn't support expressing JSON documents, which is a big problem. The only way this would work is if we allowed "@vocab": "#", where the base url would be prepended... which I'm not sure we do. I think @vocab requires an absolute IRI? @gkellogg, do we allow this? @azaroth42, you asked for "new evidence that would overturn the resolution is showing that two organizations are independently using this feature." ... that would be every organization currently using JSON-LD that doesn't do JSON-LD processing before putting the document into a document-based store such as MongoDB. So, I'm back to being in opposition of this language in the spec. More specifically:
I challenge this position. We would not have supported a charter that recommended the removal of features, even if in some advisory capacity in the future. As a member of the WG, I insist that this modification is out of scope for the charter.
This argument sounds like throwing the baby out with the bathwater. Just because there is a corner case is no reason to throw the feature out in general.
No, we don't. That approach requires modification of the term to prepend a "#' character. JSON-LD was designed to, as much as possible, be "Add a context and you're done." The feature referred to is "add a context, then rename all of your properties to something that's completely foreign to most JSON developers".
Dumbing JSON-LD down because the RDF data model doesn't support a feature that is required to express JSON is a step in the wrong direction. The response should be to fix RDF, not to remove features from JSON-LD that JSON developers rely on. The feature, just to be clear, is document-scoped predicates. To provide an analogy, when airplanes were being invented, we didn't say: "Well, buses don't have wings, so let's shear the wings off of all of the planes in the name of uniformity". |
I'm not quite sure I understand this. Isn't what you're describing just "putting JSON in a JSON store"? How does having or not having unnamed properties affect this? Can you perhaps give a concrete example of how this will stop someone from storing JSON-LD 1.1 in a JSON document store? |
|
Ok, give me a bit of time, and perhaps I can pop up a document that gives an Institution Theoretic view of RDF. In that space it is natural to start with a signature with no blank nodes as basic. Blank nodes just fall into place automatically as existential quantifiers by signature morphism from Σ→Σ+X. But when doing it looks like one automatically gets existential quantification in predicate position too. The question then if that is problematic. The Encyclopedia of Philosophy article brings up the question as to whether this is a representable substitution. (If you are interested I can look at that in more detail, but will take me some work to fully understand that and make it easy to understand) |
|
@ajs6f wrote:
We're putting JSON-LD in a JSON store.
In JSON-LD 1.0, the data model could represent doing this. What the JSON-LD 1.1 WG is suggesting is removing a feature in the data model such that the data model can no longer represent this.
It doesn't stop anyone from storing a document in a document store... it's just that the JSON-LD data model is no longer capable of expressing it in the data model. That is, it was clean from a data model perspective in JSON-LD 1.0, but is no longer JSON-LD in whatever version of JSON-LD will completely remove this feature of the data model. The fundamental point here is that the RDF data model can't represent JSON... and the JSON-LD can... and now we're discussing removing that ability from the JSON-LD model because it doesn't exist in RDF, which is the tail wagging the dog. |
|
@msporny-- I'm afraid I still don't understand. I don't see how having a unnamed property creates the situation where you can't put JSON-LD into a JSON store. I can see how it would prevent you from being able to put arbitrary JSON into, say, an LDP instance, but that doesn't seem to be what you are objecting to. Perhaps you can give a concrete example of a JSON-LD 1.0 document you'd like to put into a JSON store (e.g. MongoDB) that, after this change, you couldn't? I understand (I think) your point about the different capabilities. What I'm not clear on is what the use case actually is. We have yet to have anyone at all offer an actual concrete use case for unnamed properties. I'm not claiming at all that there are no such cases-- I, for one, would love to hear about them so that we can take them into consideration. As for the question of whether JSON-LD 1.1 must be able to represent all possible JSON constructions, I'll gladly defer to the WG chairs. That's obviously a higher-level question than this one. |
|
Promoting the notion that blank node identifiers are stable, as is implied in the 1.0 semantics, is IMHO just a bad idea. It goes against the whole notion of blank nodes. Specifically, RDF 1.1 Concepts, which is where the notion of blank node identifiers comes from in the first place, specifically says that they are not persistent or portable.
Moreover, blank node identifiers are not stable across many JSON-LD algorithms, and giving the impression that a property may map to a blank node identifier to give it meaning in the data model does not allow it to be manipulated as one would expect (other than expansion and compaction). As it's defined, given a document location and the simple use of {
"@context": {
"@vocab": "",
"foo": "#foo"
},
"foo": "bar"
}This definitely satisfies the use case, at the expense of specifically defining such otherwise unmapped terms. However, we could go further. The {
"@context": {"@vocab": "#"},
"foo": "bar"
}In retrospect, I don't know why we didn't try harder in 1.0 to avoid the use of blank nodes for properties. I'm surprised that the RDF 1.1 WG let this through, but I chalk it up to fatigue at the end of the WG and a lack of interest but some that would really care. This is the time to correct this use, and truly make JSON-LD a Linked Data format; perpetuating the use of blank node identifiers as stable parts of a JSON-LD document goes counter to the whole notion of Linked Data. |
|
This issue was discussed in a meeting.
View the transcript3.1. Consider obsoleting use of blank nodes for properties and “generalized RDF” #37Rob Sanderson: the first block of issues is around JSON syntax vs JSON-LD. … obsoleting the use of blank nodes for properties. Ivan Herman: link: #37 Rob Sanderson: we’ve discussed this and resolved it as accepted … after which Manu objected, on the grounds that our charter does not permit us to deprecate extant features Ivan Herman: I’d prefer to actually discuss this with Manu himself Rob Sanderson: Manu has delegated all the JSON-LD stuff to Dave Longley (who is not present at this time) Ivan Herman: we can close it again, but Manu will just reopen it again … I believe that his justification was basically wrong Dan Brickley: Can this be used for property graph -style usage … in which properties can have properties? Ivan Herman: JSON-LD doesn’t have that structure by itself, so you would have to rely on the RDF side, and it wouldn’t be valid there. Gregg Kellogg: If RDF supports that in the future (and work is ongoing there) and it was understood to be the correct way to do it, you could do it Dan Brickley: Wouldn’t be good to take something out when in a year it might be very handy? Leonard Rosenthol: How do you define deprecation? In ISO, we say “Don’t write it, but you can read it” Ivan Herman: There is, afaik, a formal definition for deprecation at W3C, but we don’t have it at our fingertips. … we’ll check into that Gregg Kellogg: One of the issues with deprecation is w.r.t. to semantic versioning. 1.0 vs. 1.1 vs. 2.0. We’re at 1.1, not 2.0. … we would still, by deprecating, be taking it out eventually, and Manu would probably object to that. … I’d rather add descriptive notes using “SHOULD NOT” language Benjamin Young: I work on a graph system, levelgraph.io capable of provenance for each triple, but none of that survives into JSON-LD. Benjamin Young: https://www.w3.org/Data/events/data-ws-2019/cfp.html Benjamin Young: we do need to address that, to make it possible for those systems to use JSON-LD Dan Brickley: earlier literals as subjects discussion, https://www.w3.org/2001/sw/wiki/Literals_as_Subjects Pierre-Antoine Champin: Recently, some proposals have come out showing research into the “use bnodes to add properties to properties” technique. And there are “spaces” in the SPARQL rec that allow, e.g. literals as subject. This is all generalized RDF, but is that the thing to which you want to round trip? Dan Brickley: for the record, property graphs have drivers for a lot of databases beyond neo4j Dan Brickley: http://tinkerpop.apache.org/ lists 24 graph data systems with some kind of property graph interface Ivan Herman: property graphs are great, but this WG should not have an issue for encoding property graphs in JSON-LD … that’s a 2.0 thing. … maybe in a year. … but discussion now is very premature, not appropriate for this WG … my problem with bnodes as properties is demonstrated by Manu’s reaction: one is liable to believe that one has solved a problem when the solution is, in fact, wrong. … Manu is using the preservation of bnode labels from scope to scope as a feature. … it’s not. It’s a particularity of some implementations. … he’s using a syntactical quirk as support to solve another problem. … usages of bnode-predicates is only possible within RDF/OWL derivation … certainly not a technique that anyone should be using in data, we should stick to what is in RDF … after the upcoming Berlin workshop, perhaps this could be discussed for 2.0, but not now. Dan Brickley: I am hearing the word “deprecate”, and that is scary for something with the audience of Google. … we could put versioning into resources we control (e.g. the schema.org context), but we won’t do that if it’s liable to irritate or confuse millions of people … we don’t use the bnode-property thing ourselves, at Google. … but schema.org folks have real interest in qualifying graph edges, so if this could help with that… Ivan Herman: there are other ways to do that Dan Brickley: that would be fine. Dan Brickley: we originally objected to the charter for this group, because we felt it was justified in terms of success for which Google bore responsibility. And the google-promoted schema.org rollout is powered by millions of sites who don’t follow w3c latest developments religiously. It would unfortunate to start deprecating what they do, so quickly. … we don’t want to injure our users! Ivan Herman: the CG would normally be the place where these things are discussed Gregg Kellogg: the CG is not very live now … I wouldn’t want to cut off property graphs. let’s put it on the side and deal with it at a later date … specifically after being informed by the upcoming workshop … bnodes-as-properties was not meant in support of property graphs … it was more about worries that demanding an IRI for every property would be a bridge too far for many developers. … I support Ivan’s point that the use Manu suggests is technically wrong … it’s a bad idea. there is an expectation from users that labels won’t change, but we don’t want to reinforce that Ivan Herman: the canonicalization algorithm would change those labels anyway Gregg Kellogg: there are toggles for doing that, but usually people say that canonicalized datasets are text strings, not abstract syntax Benjamin Young: This issue is for people who write contexts, not content (not instances), this is about a much smaller community than everyone who publishes JSON-LD … the confusion that can result from bnode labels not being preserved does need to be recognized and dealt with … we need to make sure that people understand what’s happening and why they need stable identifiers, perhaps in the forthcoming primer Ivan Herman: we gave examples of this happening in the rec, and we shouldn’t have done that Rob Sanderson: the original JSON-LD 1.0 use case would be covered by being able to use relative IRIs for @vocab … we should continue as we have chosen, using the term “obsolete” as HTML does—to mean “you can use this, but conforming processors will throw a warning” … and we can ask Manu and danbri whether this really is used in the wild. Dan Brickley: Pretty sure it isn’t. … but hard to say for sure. Ivan Herman: Should we close? Dan Brickley: We could put a “feature at risk” on it. Gregg Kellogg: That would be good because future people who aren’t represented in this discussion could object Dan Brickley: Can we adjust the language to not tell people they’re WRONG, but that this has implications for what you can do with your JSON-LD? Ivan Herman: It is just wrong. Benjamin Young: It may be wrong from a OWA perspective. “Culturally” wrong. Gregg Kellogg: We can’t pretend that this was experimental. We didn’t mark it as such. … there’s a good bit of explanatory text about this in 1.0. We could certainly remove that. Proposed resolution: Mark bnode as property as a Feature At-Risk for the next WD, with a view towards marking as Obsolete with a warning in 1.1 (Rob Sanderson) Gregg Kellogg: A suggested URN-based replacement for this would be good. Rob Sanderson: +1 Benjamin Young: URNs can be as fragile as bnodes, but there is a whole world of identifiers out there Ivan Herman: +1 Simon Steyskal: +1 Benjamin Young: +1 Ivan Herman: Every resolution is temporary for a week, so we can do this and still have discussion with Manu et al. Gregg Kellogg: +1 paul: +1 Pierre-Antoine Champin: +1 Adam Soroka: +1 Luc Audrain: [abstain] Dan Brickley: +0.666_ Resolution #1: Mark bnode as property as a Feature At-Risk for the next WD, with a view towards marking as Obsolete with a warning in 1.1 Pierre-Antoine Champin: I don’t think the JSON-LD spec is the right place to solve the bnode-property question Rob Sanderson: Since we have danbri for now, let’s move some relevant issues up from the afternoon |
|
over at Mastodon, I have server operators reporting a lot of “[DEPRECATION] Blank Node vocabularies deprecated in JSON-LD 1.1” in logs from the json-ld ruby gem. this seems 1) concerning, since I think we use blank node vocabularies a fair amount and 2) potentially misleading if I'm interpreting this issue correctly? |
|
The use of blank nodes as properties is marked as a feature at risk for JSON-LD 1.1, as the underlying data model does not support blank nodes as predicates, although it's seen some deployment, principally in Activity Streams. Based on feedback, we may make make it not obsolete and continue to fully support it. Are there other vocabularies you're aware of that depend on blank node properties? Presumably, if vocabularies could be updated, document-relative or URN based properties could serve the same purpose. The Ruby gem does announce the DEPRECATION message based upon this state, and if it didn't you might not be chiming in on this issue. If the AT RISK is removed, the gem will respond by removing the DEPRECATION message. @azaroth42 we should put this back on the agenda for further discussion. |
|
@nightpool Can you say a bit more about how Mastodon uses blank nodes in this way? It would be really helpful to understand how that came about and why-- it would feed healthy continued discussion about this. |
|
as far as I know activitypub messages should not contain any blank nodes if they are well formed |
|
👍 to discussion. @nightpool could you please post a message that uses blank nodes for predicates into the issue? |
|
I'm currently looking into the issue, @ThibG hasn't been able to trace down the particular document that caused the error. Here's a pretty bog-standard activitystreams document if you want to look at it: https://cybre.space/@nightpool/102541962034098460.json |
|
(i'm suspicious of the claim @kaniini makes that a well-formed as2 document will never contain blank nodes, considering that example 30 and 31 in ActivityStreams Core show a document with blank nodes) I think we've been pretty good about avoiding blank nodes in mastodon, but I can't guarantee that the rest of the fediverse doesn't use them, particularly misskey and glitch-soc. |
|
Well, one document that has |
|
@ThibG Exactly... Actually, the document provided by @nightpool does not generate any bnode predicate. Maybe the Ruby gem should only complain when an actual bnode property is generated, rather than when it encounters |
Well, I can do anything with the Ruby gem, and certainly leave any warnings to when the But, perhaps we can lay this issue to rest in the group, and if we keep it, describe what processors should do. |
I've updated the develop version of the Ruby gem to only output a DEPRECATION warning on |
|
This issue was discussed in a meeting.
View the transcriptConsider obsoleting use of blank nodes for properties and “generalized RDF”Benjamin Young: See Issue 37 Benjamin Young: we more or less already agreed to deprecate this one … but it turns out that ActivityStreams is using a bnode @vocab… Note that AS is part of AvivityPub, which is used by Mastodon and other … All those people get worrying warnings when using the AS context. Gregg Kellogg: there is a comment in there, indicating that they don’t believe that they are actually creating any property. … pchampin suggested to raise the warning only when the bnode @vocab does create a bnode property… I think that solves Mastodon’s issue. I did it in my implementation. Benjamin Young: could this warning be limited to 1.1 mode? Gregg Kellogg: yes Benjamin Young: is this the default? because these people are not parsing JSON-LD 1.1, AFAIK Gregg Kellogg: actually, that’s right, the warning is not mode dependent … the purpose of the warning is precisely to warn people that his may go away in the future Ruben Taelman: are these warnings specified in the spec or implementation specific? Gregg Kellogg: the spec says “feature at risk”. It does not actually says anything about issuing a warning. … We indeed do not specify how warnings are issued. … I usually use a ‘validation’ flag to decide whether warning are issued or not, … although obviously I didn’t to that in that case. Benjamin Young: https://w3c.github.io/json-ld-api/#h-issue-0 Benjamin Young: https://w3c.github.io/json-ld-api/#h-note-3 Benjamin Young: distributed documents are long lived, … we should take this into account when it comes to issuing warnings. … The person we are targetting here is the context author. … Hence my suggestion to limit the warning to 1.1 mode, … meaning “it will still work here, but may break in the future”. … People mining old 1.0 data will get the warning, but there is nothing they can do about it. Gregg Kellogg: without warnings, the developers will not get pressure from their user to drop deprecated features … the ‘validation’ flag is probably a good way to solve this Dave Longley: there are a lot of implementations that can only report errors, not warnings Benjamin Young: so do we need to change the spec? Gregg Kellogg: https://www.w3.org/TR/json-ld11-api/#algorithm-2 Gregg Kellogg: we need to be clearer about the bnode properties Benjamin Young: should we recommend an alternative to the bnode … such as a “fake bnode” IRI acting as a catch-all for undefined properties? … The AS context shows that there is a need for that; … JSON users do not like their properties to disappear through JSON-LD processing. Gregg Kellogg: the most suitable replacement would be " @vocab": "#"… this is common in other uses of RDF, Dave Longley: +1 to " @vocab": "#"Gregg Kellogg: and the reason why we allowed relative IRIs as @vocabBenjamin Young: #37 (comment) Benjamin Young: and in the spec Gregg Kellogg: If we provide such an alternative to bnode properties, we can change the ‘AT RISK’s to simple notes. Benjamin Young: https://www.w3.org/TR/json-ld11/#h-issue-0 Dave Longley: when we go to CR, I’m afraid people would object to bnode properties if we remove the ‘AT RISK’… Gregg Kellogg: these AT RISK are not normative. We could leave them for CR, and remove them afterwards. timecole: for me the purpose of ‘AT RISK’ is testing; it draws the attention to points that we are not sure can be implemented. Ivan Herman: timCole is right. It is used to mark features that can be removed if they lack implementation, without having to go through CR again. Proposed resolution: turn blank node issue https://www.w3.org/TR/json-ld11/#h-issue-0 into a note to suggest new context authors avoid using " @vocab": "_:" as well as direct use of blank nodes as properties. (Benjamin Young)Ivan Herman: +1 Tim Cole: +1 Gregg Kellogg: +1 Benjamin Young: +1 Ruben Taelman: +1 Adam Soroka: This would be a note that accompanies 1.1? Dave Longley: +0 fine with me Pierre-Antoine Champin: +1 Adam Soroka: +0.5 Resolution #2: turn blank node issue https://www.w3.org/TR/json-ld11/#h-issue-0 into a note to suggest new context authors avoid using " @vocab": "_:" as well as direct use of blank nodes as properties.Gregg Kellogg: we will then turn the ‘AT RISK’ issues into notes; … we will recommend to use # relative IRIs instead; … we will suggest to issue a warning whenever a bnode property is generated. … None of these points are normative. So they don’t need more WG action. Dave Longley: if don’t have a base IRI set and use a relative IRI for the … then properties will still be dropped when converted to RDF. … So we are improving the situation, but not solving it 100%. Proposed resolution: close #37 once blank node property issue is changed to a note (Benjamin Young) Ivan Herman: +1 Benjamin Young: +1 Dave Longley: +1 Pierre-Antoine Champin: +1 Ruben Taelman: +1 Gregg Kellogg: +1 Tim Cole: +1 Resolution #3: close #37 once blank node property issue is changed to a note |
|
Fixed in d90066f and w3c/json-ld-api@2bb7eb4. |
This is one of the major things that makes JSON-LD out of step with the RDF data model, and it's not clear if the feature is used or valuable. IIRC, the original issue was making it easy to support mapping ad-hoc JSON structures without creating IRIs, but the use of
@vocab, and document-relative IRIs for properties would seem to obviate the need for this.This would likely prohibit the direct use of blank node identifiers in the property position, as well as the mapping of terms to blank node identifiers.
Downsides: another area of potential incompatibility with JSON-LD 1.0. A backwards-compatible solution would be to preserve the feature, but mark it archaic. This might cause warnings to be generated if encountered with a processor running in 1.1 mode.
The text was updated successfully, but these errors were encountered: